search for: dw_at_ranges

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 clan...

There's no requirement that DW_AT_ranges (or high/low_pc) appear on the skeleton CU rather than the DWO CU. So it's quite possible that to get the 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 (bec...

...direction. If it is an > advantage across the board we can remove the option 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...

(Reviving this thread because a code review reminded me I want to reply here. Sorry for the extremely long turnaround). On 31/03/2020 20:22, Fangrui Song wrote: > On 2020-03-31, Adrian Prantl via llvm-dev wrote: >> >> >>> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> +1 to all that & cc'ing a few of the

...ion and just make this the > > default behavior. > > > > thanks, > > 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...

...I often can't get the compiler to emit what I need > to test with DWARF. For example, I needed to create a compile unit with > three functions: two of the functions need to look like they are dead > stripped (with an address of zero) and they need to come first in the > compile unit DW_AT_ranges. Also the compile unit needs to use a > DW_AT_ranges attribute for the address ranges of each of the functions and > I need to control the ordering. If I compile something like this from a > source file, the compiler users a DW_AT_low_pc and DW_AT_high_pc and I have > no DW_AT_ranges on...

...least DW_RLE_base_addressx > entries (or the CU needs to set its DW_AT_low_pc referencing the > .debug_addr section). If that's in place we can generate all the *x entry > kinds (DW_RLE_startx_endx etc.) > > - Generating the offset table and using DW_FORM_rnglistx with the > DW_AT_ranges attribute. This should cut down further on the relocations > the linker needs to perform. > > Also, I am currently working on a refactor of the .debug_rnglists dumper > (reader) part. The rationale is that the location list table in > .debug_loclists is identical in layout to the ra...

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

David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > wrote: > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the >> skeleton CU rather than the DWO CU. So it's quite possible that to get the >> 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? >> >>...

?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):

...havior. >>>> > >>>> > 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 compressio...

...sultant llvm-dwarfdump -verbose -verify is run I get a bunch of the following errors: warning: could not find referenced DIE in DIE: 0x0000a33f: DW_TAG_inlined_subroutine [20] * DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x0c84 => {0x0000a40d}) DW_AT_ranges [DW_FORM_sec_offset] (0x00021960 [0x0000000000001878 - 0x000000000000187c) [0x00000000000018b0 - 0x0000000000001910) [0x0000000000001980 - 0x00000000000019e0)) DW_AT_call_file [DW_FORM_data1] ("<mypath&...

Hi all, I've put this email in a different thread, although it is quite similar to some of the threads on tombstoning etc, with similar underlying structural issues. Whilst prototyping my fragmented DWARF idea for GC-ing DWARF sections properly, I ran into an object in the game code I was using as my input where a v4 .debug_loc section had a location description that looked something like

Can you add some tests? On 26 October 2012 10:55, Daniel Kłobuszewski <daniel.klobuszewski at ibs.org.pl> wrote: > Hello, > > Recently I found binaries produced with LLVM impossible to debug under > Windows. This was probably related to the following bug: > http://llvm.org/bugs/show_bug.cgi?id=13636 > > Asm generated from .ll files revealed that some offsets to debug

...pindola < rafael.espindola at gmail.com> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > > wrote: > > > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the > >> skeleton CU rather than the DWO CU. So it's quite possible that to get > the > >> address ranges covered by the CU one would need to look in the DWO, I > think? > >> > >> Is that not correct/have I misunderstood somet...

...ltant llvm-dwarfdump -verbose -verify is run I get a bunch of the following errors: warning: could not find referenced DIE     in DIE: 0x0000a33f:      DW_TAG_inlined_subroutine [20] *                     DW_AT_abstract_origin [DW_FORM_ref4]    (cu + 0x0c84 => {0x0000a40d})                     DW_AT_ranges [DW_FORM_sec_offset]    (0x00021960                       [0x0000000000001878 - 0x000000000000187c)                       [0x00000000000018b0 - 0x0000000000001910)                       [0x0000000000001980 - 0x00000000000019e0))                     DW_AT_call_file [DW_FORM_data1]    ("<mypa...

Hello, Recently I found binaries produced with LLVM impossible to debug under Windows. This was probably related to the following bug: http://llvm.org/bugs/show_bug.cgi?id=13636 Asm generated from .ll files revealed that some offsets to debug information were incorrect: they were absolute instead of relative to their sections. Following patch seemed to have repaired the problem, so I'm

...and be indistinguishable from normal address ranges. eg: __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } int main() { } $ clang++ rng.cpp -fuse-ld=lld -Wl,-gc-sections -g && llvm-dwarfdump a.out DW_TAG_compile_unit DW_AT_ranges (0x00000000 [0x0000000000000000, 0x0000000000000016) [0x0000000000400540, 0x0000000000400548)) ... DW_TAG_subprogram DW_AT_low_pc (0x0000000000000000) DW_AT_high_pc (0x0000000000000006) DW_AT_name ("f1") ... DW_TAG_subprogram DW_AT_low_pc (0x0...

...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 these problems - but I think there's still a lot of overhead to making a solution that's workable with a DWARF-agnostic linker (or even with a DWARF aware one, but in an efficient amount of time...

...> > >__attribute__((section(".text.x"))) void f1() { } > >__attribute__((section(".text.x"))) void f2() { } > >int main() { } > >$ clang++ rng.cpp -fuse-ld=lld -Wl,-gc-sections -g && llvm-dwarfdump a.out > >DW_TAG_compile_unit > > DW_AT_ranges (0x00000000 > > [0x0000000000000000, 0x0000000000000016) > > [0x0000000000400540, 0x0000000000400548)) > >... > > DW_TAG_subprogram > > DW_AT_low_pc (0x0000000000000000) > > DW_AT_high_pc (0x0000000000000006) > > DW_AT_name (&...