search for: debug_range

Displaying 20 results from an estimated 107 matches for "debug_range".

Did you mean: debug_ranges
2020 May 31
2
Range lists, zero-length functions, linker gc
...>> 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...
2020 Apr 27
2
[yaml2obj] GSoC-20: Add DWARF support to yaml2obj
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...
2020 May 29
2
Range lists, zero-length functions, linker gc
...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...
2020 May 31
3
Range lists, zero-length functions, linker gc
...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...
2020 May 29
2
Range lists, zero-length functions, linker gc
...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...
2020 May 29
4
Range lists, zero-length functions, linker gc
...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...
2020 May 28
2
Range lists, zero-length functions, linker gc
...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...
2020 Nov 04
3
Fragmented DWARF
...-------------- > 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 >...
2020 Jul 21
3
Switch to ld.bfd tombstone behavior by default
...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...
2020 Jul 24
2
Switch to ld.bfd tombstone behavior by default
...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...
2020 Jul 29
2
Switch to ld.bfd tombstone behavior by default
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...
2020 Jul 24
2
Switch to ld.bfd tombstone behavior by default
...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: > > >> >...
2020 Jul 30
3
Switch to ld.bfd tombstone behavior by default
...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 '...
2020 Jul 25
2
Switch to ld.bfd tombstone behavior by default
>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...
2020 Aug 05
2
Switch to ld.bfd tombstone behavior by default
...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' >&...
2020 Jul 27
2
Switch to ld.bfd tombstone behavior by default
...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...
2020 Aug 05
3
Switch to ld.bfd tombstone behavior by default
...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...
2020 Jul 20
2
Switch to ld.bfd tombstone behavior by default
...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...
2017 Aug 07
4
DWARF: Ranges base address specifier entries & Gold's gdb-index 32 bit bug
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...
2020 Aug 05
2
Switch to ld.bfd tombstone behavior by default
...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"...