search for: dwarf64

In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to join the group before making a post) Cary Coutant raised yet another idea: whether we can use ".debug64" as the section prefix. I like the idea because of: * It is immediately obvious whether DWARF64 is used and whether DWARF32 is used along with DWARF64. * In a relocatable link mixing DWARF32 and DWARF64 sections, DWARF32 and DWARF64 sections will naturally not get mixed. (For a relocation based approach, if DWARF64 is the first input section, the output may appear as a "DWARF64" bec...

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all input sections are SHT_DWARF64, the output section type probably > > should also be SHT_DWARF64. > > If mixed, SHT_PROGBITS. > > I am not rea...

...t; In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to > join the group before making a post) > Cary Coutant raised yet another idea: whether we can use ".debug64" as > the section prefix. I like the idea because of: > > * It is immediately obvious whether DWARF64 is used and whether > DWARF32 is used along with DWARF64. > * In a relocatable link mixing DWARF32 and DWARF64 sections, DWARF32 > and DWARF64 sections will naturally not get mixed. (For a relocation > based approach, if DWARF64 is the first input section, the output may > appear as...

...; > > > > > > I got replies from Nick Clifton and Michael Matz: > > > > https://sourceware.org/pipermail/binutils/2020-November/114116.html > > > > (and its reply). > > > > I have mentioned (a) the difficulty of the > > > > detecting-DWARF64-by-first-relocation approach and (b) the section > > > > type approach in my reply there > > > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > > > > > (a) My prototype has made me feel uneasy with this approach. > &gt...

Thinking about it, it would probably be wise to raise this discussion on the DWARF mailing list too. They might want to put an addendum in the spec/DWARF wiki/somewhere appropriate along the lines of "ELF support for DWARF64", which can be retroactively applied to existing standards. The committee may also have some thoughts on how tools are expected to work with DWARF64 and DWARF32 mixtures. James On Tue, 17 Nov 2020 at 07:06, Fāng-ruì Sòng <maskray at google.com> wrote: > On Mon, Nov 16, 2020 at 10:4...

...vich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, or R_X86_64_64, depending on DWARF format. > >A situation we might have is that an input .debug_info section is DWARF32 so it gets order...

On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > For .debug_* in object files: > > DWARF32 -> SHT_PROGBITS (unchanged) > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > all input sections are SHT_DWARF64, the output section type probably > should also be SHT_DWARF64. > If mixed, SHT_PROGBITS. I am not really sure that we need a new secti...

...dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer the relocation based approach: if a .debug_* has an 64-bit absolute relocation type (e.g. R_X86_64_64). In LLD, for an input section, we don't know its associated SHT_REL[A] section. So when adding an orphan section we would ha...

....com>; llvm- > dev at lists.llvm.org; Robinson, Paul <paul.robinson at sony.com>; James > Henderson <jh7370.2008 at my.bristol.ac.uk>; Eric Christopher > <echristo at gmail.com>; Igor Kudrin <ikudrin at accesssoftek.com> > Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting" > > On 2020-11-14, Alexander Yermolovich wrote: > >Thanks for doing a diff and asking in other groups. > > > >So if I understand your concern with using first reloc as it relates to > .debug_str. > > > >In DWARF4 for .debug_str...

I got replies from Nick Clifton and Michael Matz: https://sourceware.org/pipermail/binutils/2020-November/114116.html (and its reply). I have mentioned (a) the difficulty of the detecting-DWARF64-by-first-relocation approach and (b) the section type approach in my reply there https://sourceware.org/pipermail/binutils/2020-November/114125.html (a) My prototype has made me feel uneasy with this approach. <quote> In DWARF v4 or if .debug_str_offset is not used, it is a problem. A heur...

This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a mix of CU that are DWARF32/64. This is s...

...objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects etc), so we do need to consider this approach." David can you elaborate under which conditions LTO-generated objects will have a mix of DWARF32/64 in same .debug_info? Looking at how dwarf64 was implemented same flag will be used for the entirety of the dwarf output, even if multiple CUs are included. I think if object does have a mix of CUs that are 32/64, linker can do a best effort ordering, and output a warning. My approach to this is from covering common cases while solving a pro...

...Fāng-ruì Sòng <maskray at google.com> wrote: > > > > I got replies from Nick Clifton and Michael Matz: > > https://sourceware.org/pipermail/binutils/2020-November/114116.html > > (and its reply). > > I have mentioned (a) the difficulty of the > > detecting-DWARF64-by-first-relocation approach and (b) the section > > type approach in my reply there > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > (a) My prototype has made me feel uneasy with this approach. > > > > <quote> > > In D...

Thanks for doing a diff and asking in other groups. So if I understand your concern with using first reloc as it relates to .debug_str. In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, or R_X86_64_64, depending on DWARF format. A situation we might have is that an input .debug_info section is DWARF32 so it gets ordered aprop...

...Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > I got replies from Nick Clifton and Michael Matz: > https://sourceware.org/pipermail/binutils/2020-November/114116.html > (and its reply). > I have mentioned (a) the difficulty of the > detecting-DWARF64-by-first-relocation approach and (b) the section > type approach in my reply there > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > (a) My prototype has made me feel uneasy with this approach. > > <quote> > In DWARF v4 or if .debug_str_offset is...

On Wed, Nov 11, 2020 at 12:19 AM Alexander Yermolovich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This year Igor Kudrin put in a lot of work in enabling DWARF64 support in > LLVM. At Facebook we are looking into it as one of the options for handling > debug information over 4gigs in production environment. One concern is that > due to mix of third party libraries and llvm compiled code the final > library/binary will have a mix of CU that are D...

Looks like there is an agreement that this path, modifying lld to order sections using relocations, should be explored. If Igor doesn't object, since he was primary one driving DWARF64 so far, I would like to give it a shot at implementing and collecting some performance numbers. 🙂 Alex ________________________________ From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Thursday, November 12, 2020 2:20 AM To: Fangrui Song <maskray at google.com> Cc: Alexan...

...google.com> wrote: > > > > > > I got replies from Nick Clifton and Michael Matz: > > > https://sourceware.org/pipermail/binutils/2020-November/114116.html > > > (and its reply). > > > I have mentioned (a) the difficulty of the > > > detecting-DWARF64-by-first-relocation approach and (b) the section > > > type approach in my reply there > > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > > > (a) My prototype has made me feel uneasy with this approach. > > > > > &gt...

...s that >> communicate DWARF32/64 - some sections don't >> (debug_ranges/loc/str/macro for instance, if I recall correctly)... >> and if something has some 4 and 5, does it get sorted to the start? I >> guess so. >> > I assume this comment is meant to say DWARF32/DWARF64, not DWARFv4 and DWARFv5, as the DWARF version (as opposed to the 32/64 bit style) is irrelevant to this, I believe, at least for the current known DWARF standards. Yep! thanks for the correction - had a lot of DWARFv4/v5 on my mind due to other work, so got the terms jumbled up. > Whilst the...

...inking about it, I wouldn't expect an LTO generated object itself to have a mixture of DWARF32/64, although I guess the 32/64 bit state could be encoded in the IR (I am not familiar enough with it to know if it actually is or not). It might be necessary to find ways to configure LTO to generate DWARF64, possibly via a link-time option. I don’t think we need to encode dwarf32/64 in IR as attribute for each module. We’re not going to emit mixed dwarf32/64 for merged LTO module anyways, so allowing each module to express its dwarf setting would only introduce burden for LTO to deal with inconsisten...