search for: dwarf32

...; (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 have another loo...

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

...k 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 supported by DWARF format. With this mix it is possible that even with DWARF64 enabled one can still encounter relocation overflows errors in LLD if DWARF32 sections happen to be processed towards the end. One proposal that was discussed in https://reviews.llvm.org/D87011, is to modify...

...and check /all/ contributions coming from a given input >> object file (it might contain a combination of DWARFv4 and DWARFv5) >> and then the hairy uncertainty of which sections to check (do you >> check them all? well, all the ones with length prefixes 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, a...

...o be able to jump over contributions and check /all/ contributions coming from a given input object file (it might contain a combination of DWARFv4 and DWARFv5) and then the hairy uncertainty of which sections to check (do you check them all? well, all the ones with length prefixes 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. On Tue, Nov 10, 2020 at 9:30 PM Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > &g...

...was a better way. "Whilst the majority of 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...

...attributes, they can probably update the build configuration of > > > those objects to build them with DWARF64 instead, avoiding the mixed > > > 32/64 problem. I think the solution we're looking for would have to > > > work with existing precompiled object files using DWARF32 that are in > > > the wild today, without modification. > > > > I know the "no-modification" requirement:) The first paragraph of > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > mentioned this. > > OK - thanks for clarifyi...

...n 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" because the proposed approach o...

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. > &g...

> Thinking 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 att...

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

...t; contributions and check /all/ contributions coming from a given input > object file (it might contain a combination of DWARFv4 and DWARFv5) > and then the hairy uncertainty of which sections to check (do you > check them all? well, all the ones with length prefixes 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 vers...

...The end "symptoms" being tested aren't much different in each case, so it makes sense to share the test code as much as possible. Without Combine, I have to do the following: INSTANTIATE_TEST_CASE_P( LineTableTestParams, DebugLineParameterisedFixture, Values(std::make_pair(2, DWARF32), std::make_pair(3, DWARF32), std::make_pair(4, DWARF32), std::make_pair(5, DWARF32), std::make_pair(2, DWARF64), std::make_pair(3, DWARF64), std::make_pair(4, DWARF64), std::make_pair(5, DWARF64))); I realised whilst typing this out, that I don't need a distin...

...rebuild objects with > new attributes, they can probably update the build configuration of > those objects to build them with DWARF64 instead, avoiding the mixed > 32/64 problem. I think the solution we're looking for would have to > work with existing precompiled object files using DWARF32 that are in > the wild today, without modification. I know the "no-modification" requirement:) The first paragraph of https://sourceware.org/pipermail/binutils/2020-November/114125.html mentioned this. The section type approach is used this way (in another paragraph): <quote>...

..., 2020 at 9:52 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 8:35 AM Wenlei He via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > > Thinking 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...

...way. > >"Whilst the majority of 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...

.../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" because the...

...tributions coming from a given input > >> object file (it might contain a combination of DWARFv4 and DWARFv5) > >> and then the hairy uncertainty of which sections to check (do you > >> check them all? well, all the ones with length prefixes 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, n...

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

On Thu, Mar 15, 2018 at 9:09 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > > Could you provide an example here of the motivation for the feature you're > missing? Might help motivate the discussion (and/or we'll end up nitpicking > how it could be done differently without that feature... - which