search for: debug_addr

...bug_rnglists and .debug_loclists done, you can ask for DWARF 5 and get something that conforms to the spec. However, it won't conform if you ask for type units (I'm working on that) or split DWARF. If your motivation is to help reduce the number of relocations needed, then working on the .debug_addr section is definitely the next step. This will reduce relocations in pretty much every other DWARF section. If you have other goals, let us know what they are. Thanks, --paulr > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via > ll...

...address ranges covered by the CU one would need to look in the DWO, I think? Is that not correct/have I misunderstood something there? The DWO isn't supposed to contain addresses (because it isn't supposed to contain relocations). In DWARF 5 the DWO can have FORM_addrx references to the .debug_addr section in the main .o file, which allows the DWO to contain DIEs/attributes that should have address values, because the actual address values are still in the .o file; but before that anything that's an address really can't go into the DWO. Unless I am also misunderstanding something… --...

Hello Wolfgang and team, I see that you are working on support of .debug_rnglists, I am interested in the feature too, could you please point me out what else left to be done so that I could help you? -- Best Regards, Victor Leschuk | Software Engineer | Access Softek

...ook in the DWO, I think? >> >> Is that not correct/have I misunderstood something there? >> >> The DWO isn't supposed to contain addresses (because it isn't supposed to >> contain relocations). In DWARF 5 the DWO can have FORM_addrx references to >> the .debug_addr section in the main .o file, which allows the DWO to >> contain DIEs/attributes that should have address values, because the actual >> address values are still in the .o file; but before that anything that's an >> address really can't go into the DWO. >> > > DW...

...cleanup to share some of > > teh implementation with rnglist emission, not a compliance issue) > > You might want to look at default location entry then; particularly if a > variable moves around but has a stack home, it can reduce the number of > entries and maybe eliminate some .debug_addr references. > I don't think it'd reduce debug_addr references - I'm setting it up to only use the base address of the function start and everything's offset pairs from there, so loclists shouldn't create any addr entries, only using existing ones needed for the function'...

On Wed, Oct 9, 2019 at 1:33 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > From: David Blaikie <dblaikie at gmail.com> > >> On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <mailto: > paul.robinson at sony.com> wrote: > >> There are many bits of DWARF-5 that haven’t been implemented. > > > > Got a short list, by chance? > > I

...gt; >> Is that not correct/have I misunderstood something there? > >> > >> The DWO isn't supposed to contain addresses (because it isn't supposed > to > >> contain relocations). In DWARF 5 the DWO can have FORM_addrx > references to > >> the .debug_addr section in the main .o file, which allows the DWO to > >> contain DIEs/attributes that should have address values, because the > actual > >> address values are still in the .o file; but before that anything > that's an > >> address really can't go into the D...

tl;dr: in DWARFv5, using DW_AT_ranges even when the range is contiguous reduces linked, uncompressed debug_addr size for optimized builds by 93% and reduces total .o file size (with compression and split) by 15%. It does grow .dwo file size a bit - DWARFv5, no compression, not split shows the net effect if all bytes are equal: -O3 clang binary grows by 0.4%, -O0 clang binary shrinks by 0.1% Should we enable...

...e. All that said, to avoid burying the lede here, I'll splice something from the end up here: > Although the point is not to avoid tombstone values, but to do a more efficient job of editing the final DWARF to omit gc'd functions; it's no problem at all to use a tombstone value in .debug_addr IMO. But the tombstone values are Alexey's underlying issue (this ongoing design discussion for over a year now) & /sort/ of mine too recently (which, unfortunately, is what's reinvigoraetd this discussion - would've been nice if I/we/someone had identified this sooner & could&...

..., I'll splice something > > from the end up here: > > > > > Although the point is not to avoid tombstone values, but to do a more > > efficient job of editing the final DWARF to omit gc'd functions; it's no > > problem at all to use a tombstone value in .debug_addr IMO. > > > > But the tombstone values are Alexey's underlying issue (this ongoing > > design discussion for over a year now) & /sort/ of mine too recently > > (which, unfortunately, is what's reinvigoraetd this discussion - > > would've been nice if I/w...

...lf64_Shdr) = 64.") & it would probably be rather difficult to reconstruct header-less slice-and-dicable sections in some cases. For type information (a reduced overhead version of -fdebug-types-section) I could see it - but for functions, they need to refer to addresses - preferably in the debug_addr section, and that's accessed by index, so taking chunks out of it would break other references to it, etc... adding the header would be expensive, and how would the CU construct its DW_AT_ranges value if that has to be sliced and diced? Again, some amount of linker magic might solve some of the...

...and just make this the > default behavior. > > thanks, > adrian > > > On Dec 30, 2019, at 12:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > tl;dr: in DWARFv5, using DW_AT_ranges even when the range is contiguous > reduces linked, uncompressed debug_addr size for optimized builds by 93% > and reduces total .o file size (with compression and split) by 15%. It > does grow .dwo file size a bit - DWARFv5, no compression, not split shows > the net effect if all bytes are equal: -O3 clang binary grows by 0.4%, -O0 > clang binary shrinks by 0....

...tion which needs to have an additional specification. There is -fdebug-types-section implementation which follows that recommendation.  Other cases(other than type units) do not easily fit into this recommendation. There are tables which have a common header. F.e. .debug_line, .debug_rnglists, .debug_addr. It is not clear how these tables could be separated between section groups. The more important thing is the fragmentation itself. Dividing debug tables into pieces would increase debug info size. It also would significantly complicate code working with debug info. F.e. include/llvm/DebugInfo/D...

...{ *(.debug_funcnames) } + .debug_typenames 0 : { *(.debug_typenames) } + .debug_varnames 0 : { *(.debug_varnames) } + /* DWARF 3 */ + .debug_pubtypes 0 : { *(.debug_pubtypes) } + .debug_ranges 0 : { *(.debug_ranges) } + /* DWARF Extension. */ + .debug_macro 0 : { *(.debug_macro) } + .debug_addr 0 : { *(.debug_addr) } + .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) } + /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } +} diff --git a/usr/klibc/arch/ia64/pipe.S b/usr/klibc/arch/ia64/pipe.S index 8ecd972..ae31a3a 100644 --- a/usr/klibc/arch/ia64/pipe.S +++ b/usr/klib...

...t; > adrian > > > > > On Dec 30, 2019, at 12:08 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: > > > > > > tl;dr: in DWARFv5, using DW_AT_ranges even when the range is contiguous > > reduces linked, uncompressed debug_addr size for optimized builds by 93% > > and reduces total .o file size (with compression and split) by 15%. It > > does grow .dwo file size a bit - DWARFv5, no compression, not split shows > > the net effect if all bytes are equal: -O3 clang binary grows by 0.4%, -O0 > > clang...

...n describe more of what happened to the original program; also hopefully any efficiency improvements will allow the debugger to be more responsive. * This is obviously about DWARF itself, although to some extent how we go about generating it. * Take better advantage of ranges and the .debug_addr table. dblaikie and clayborg have put up ideas about this. * Figure out a way to allow tracking multiple source locations for an individual instruction. Right now we mostly give up and set locations to line-0 when this happens. * Understand the competing needs of profiling and debug...

...{ *(.debug_funcnames) } + .debug_typenames 0 : { *(.debug_typenames) } + .debug_varnames 0 : { *(.debug_varnames) } + /* DWARF 3 */ + .debug_pubtypes 0 : { *(.debug_pubtypes) } + .debug_ranges 0 : { *(.debug_ranges) } + /* DWARF Extension. */ + .debug_macro 0 : { *(.debug_macro) } + .debug_addr 0 : { *(.debug_addr) } + .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) } + /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } +} diff --git a/usr/klibc/arch/ia64/pipe.S b/usr/klibc/arch/ia64/pipe.S index 8ecd972..ae31a3a 100644 --- a/usr/klibc/arch/ia64/pipe.S +++ b/usr/klib...

...t;> specification. >> There is -fdebug-types-section implementation which follows that >> recommendation. Other cases(other than type units) do not easily fit into >> this recommendation. There are tables which have a common header. F.e. >> .debug_line, .debug_rnglists, .debug_addr. It is not clear how these tables >> could be separated between section groups. >> >> The more important thing is the fragmentation itself. Dividing debug >> tables into pieces would increase debug info size. >> It also would significantly complicate code working with...

?Hi ! I have a question about code used for collecting ranges. I was trying to fix PR35199. Its issue that it calls unreachable when calls DWARFObject::getFileName(). We do not implement this method in LLD and it fails. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following code (lines 335-339):

...>> > >>>> > > On Dec 30, 2019, at 12:08 PM, David Blaikie <dblaikie at gmail.com> wrote: >>>> > > >>>> > > tl;dr: in DWARFv5, using DW_AT_ranges even when the range is contiguous >>>> > reduces linked, uncompressed debug_addr size for optimized builds by 93% >>>> > and reduces total .o file size (with compression and split) by 15%. It >>>> > does grow .dwo file size a bit - DWARFv5, no compression, not split shows >>>> > the net effect if all bytes are equal: -O3 clang binary...