Re: [PATCH v3 09/19] unwind: Introduce sframe user space unwinding
Nick Desaulniers <[email protected]>
| Newsgroups | org.kernel.vger.linux-toolchains,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users |
|---|---|
| Message-ID | <CAKwvOdmZYFhz0djG0_CgQ94BLaW8rUmdW+zaoZ0G+r76Esf2+Q@mail.gmail.com> |
On Thu, Oct 31, 2024 at 1:57 PM Andrii Nakryiko <[email protected]> wrote: > > On Tue, Oct 29, 2024 at 10:53 PM Josh Poimboeuf <[email protected]> wrote: > > > > On Tue, Oct 29, 2024 at 04:32:40PM -0700, Andrii Nakryiko wrote: > > > > +static int find_fde(struct sframe_section *sec, unsigned long ip, > > > > + struct sframe_fde *fde) > > > > +{ > > > > + struct sframe_fde __user *first, *last, *found = NULL; > > > > + u32 ip_off, func_off_low = 0, func_off_high = -1; > > > > + > > > > + ip_off = ip - sec->sframe_addr; > > > > > > what if ip_off is larger than 4GB? ELF section can be bigger than 4GB, right? > > > > That's baked into sframe v2. > > I believe we do have large production binaries with more than 4GB of > text, what are we going to do about them? It would be interesting to > hear sframe people's opinion. Adding such a far-reaching new format in > 2024 with these limitations is kind of sad. At the very least maybe we > should allow some form of chaining sframe definitions to cover more > than 4GB segments? Please CC relevant folks, I'm wondering what > they're thinking about this. FWIW, Google has such large binaries, too. https://llvm.org/devmtg/2023-10/slides/quicktalks/Eubanks-CompromisesWithLargeX86-64Binaries.pdf -- Thanks, ~Nick Desaulniers