search for: debug_range

...>> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical > >> > base > >> > > > >> address for shared libraries, I’d think using it has the potential > >> > to > >> > > > >> mislead various consumers.) For .debug_ranges we use -2, because > >> > both > >> > > > a > >> > > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > >> > > > >> > >> > > > > > >> > > > >Any harm in us...

I believe the compiler will generate a .debug_ranges section if you use -ffunction-sections, since the addresses of sections will be non-contiguous. From there, you should be able to edit the .debug_ranges assembly as needed (replace references to symbols with 0s in the .debug_ranges content) to get the exact behaviour you want (I'm assuming you...

...t; > that’s a > > > > >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical > > base > > > > >> address for shared libraries, I’d think using it has the potential > > to > > > > >> mislead various consumers.) For .debug_ranges we use -2, because > > both > > > > a > > > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > > > > >> > > > > > > > > > >Any harm in using -2 everywhere, for consistency? > > > &gt...

...ress than 0x0 or 0x1. (0x0 is a typical > >> >> > base > >> >> > > > >> address for shared libraries, I’d think using it has the potential > >> >> > to > >> >> > > > >> mislead various consumers.) For .debug_ranges we use -2, because > >> >> > both > >> >> > > > a > >> >> > > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > >> >> > > > >> > >> >> > > > > &g...

...ped functions (of any length) using -1, because > > that’s a > > >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base > > >> address for shared libraries, I’d think using it has the potential to > > >> mislead various consumers.) For .debug_ranges we use -2, because both > > a > > >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. > > >> > > > > > >Any harm in using -2 everywhere, for consistency? > > > > When resolving a relocation, in certain cases we have to g...

...rences from >> debug info to stripped functions (of any length) using -1, because that’s a >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base >> address for shared libraries, I’d think using it has the potential to >> mislead various consumers.) For .debug_ranges we use -2, because both a >> 0/0 pair and a -1/-1 pair have a reserved meaning in that section. >> > >Any harm in using -2 everywhere, for consistency? When resolving a relocation, in certain cases we have to give an undefined symbol a value. This can happen with: * an undefine...

...Sony generally fixes up references from debug info to stripped functions (of any length) using -1, because that's a less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base address for shared libraries, I'd think using it has the potential to mislead various consumers.) For .debug_ranges we use -2, because both a 0/0 pair and a -1/-1 pair have a reserved meaning in that section. If you're looking only at zero-length functions, you can stop there; but I'm not sure why stopping there solves much of a real problem, as zero-length functions seem like a weird corner case. Link...

...-------------- > 41.1% 2.64Mi 0.0% 0 .debug_info > 24.9% 1.60Mi 0.0% 0 .debug_str > 12.6% 827Ki 0.0% 0 .debug_line > 6.5% 428Ki 63.8% 428Ki .text > 4.8% 317Ki 0.0% 0 .strtab > 3.4% 223Ki 0.0% 0 .debug_ranges > 2.0% 133Ki 19.8% 133Ki .eh_frame > 1.7% 110Ki 0.0% 0 .symtab > 1.2% 77.6Ki 0.0% 0 .debug_abbrev > > b) > > FILE SIZE VM SIZE > -------------- -------------- > 40.2% 2.10Mi 0.0% 0 .debug_info >...

...dat deduplicated, or gc-sections use). >> >> >> > >> >> >> >A very quick summary of the situation: >> >> >> > >> >> >> >Original Behavior: >> >> >> > >> >> >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 >> >> >> > elsewhere >> >> >> > - gold/lld: 0+addend everywhere >> >> >> > >> >> >> >Limitations/bugs: >> >> >> > >> >> >> > - bf...

...gt;> >> >> >A very quick summary of the situation: >>> > >> >> >> > >>> > >> >> >> >Original Behavior: >>> > >> >> >> > >>> > >> >> >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 >>> > >> >> >> > elsewhere >>> > >> >> >> > - gold/lld: 0+addend everywhere >>> > >> >> >> > >>> > >> >> >> >Limitations/bu...

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jul 27, 2020 at 9:11 AM Robinson, Paul <paul.robinson at sony.com> wrote: >> &gt...

...t;> >> > > > >> >> >> >A very quick summary of the situation: > > >> >> >> > > > >> >> >> >Original Behavior: > > >> >> >> > > > >> >> >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the > list), 0 > > >> >> >> > elsewhere > > >> >> >> > - gold/lld: 0+addend everywhere > > >> >> >> > > > >> >> >> >Limitations/bugs: > > >> >...

...y. Moreover, the user has to look up the semantics of 'bfd'. And the 'bfd' semantics may get stale if GNU ld updates its behaviors. We can also take it from another perspective, do the opt-in options look intimidating just because they are too long? -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe' -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe' -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff' We can support signed integers: -z 'dead-reloc-in-nonalloc=.debug_ranges=-2' -z 'dead-reloc-in-nonalloc=.debug_loc=-2' -z '...

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b). On Fri, Jul 24, 2020 at 9:33 AM Hans Wennborg <hans at chromium.org> wrote: > On Fri...

...f >> 'bfd'. And the 'bfd' semantics may get stale if GNU ld updates its behaviors. >> >> We can also take it from another perspective, do the opt-in options look >> intimidating just because they are too long? >> >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe' >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe' >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff' >> >> We can support signed integers: >> >> -z 'dead-reloc-in-nonalloc=.debug_ranges=-2' >&...

...and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730<https://urldefense.com/v3/__https:/chromium-review.googlesource.com/c/breakpad/breakpad/*/2317730__;Kw!!JmoZiZGBv3RvKRSx!ofVK1otXjQ1pPSV3TC8HS9Gwe9JwuC91OgFyvfCtZ57p55u8aHljgBgPTWYCu7N-Fg$> > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b). On Fri, Jul 24, 2020 at 9:33 AM Hans Wennborg <hans at chromium.org<mailto:hans at chrom...

...mantics may get stale if GNU ld updates its behaviors. > > >> > > >> We can also take it from another perspective, do the opt-in options look > > >> intimidating just because they are too long? > > >> > > >> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe' > > >> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe' > > >> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff' > > >> > > >> We can support signed integers: > > >> > > >&gt...

...ections to dead >> >> >code (either comdat deduplicated, or gc-sections use). >> >> > >> >> >A very quick summary of the situation: >> >> > >> >> >Original Behavior: >> >> > >> >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 >> >> > elsewhere >> >> > - gold/lld: 0+addend everywhere >> >> > >> >> >Limitations/bugs: >> >> > >> >> > - bfd/gold/lld >> >> > - doesn't suppor...

Context: In r309526 (with a followup fix in r309529) I implemented the use of DWARF's debug_ranges base address specifier entries to reduce the number of object file relocations needed for debug_ranges*. * in a particular binary internally, an optimized build had a 70% reduction in debug_ranges.reloc, a 16% decrease in total object size (with compressed debug info and fission) Nico noted that...

...yone. Thanks! -eric On Wed, Aug 5, 2020 at 12:13 PM Hans Wennborg <hans at chromium.org> wrote: > My apologies, I didn't realize D84825 now restores the original > behavior. The review thread is a bit hard to follow :-) > > From the change description it still sounds like .debug_ranges & > .debug_loc tombstones are changing to -2 though? Or is that what we > had before? > > To be clear, I'm not familiar with the technical details here, I'm > just keen that we end up in a known-good state. > > Also the patch is marked "release/11.x only"...