Igor Kudrin via llvm-dev
2020-Nov-11 08:50 UTC
[llvm-dev] [LLD] Support DWARF64, debug_info "sorting"
Thanks Alexander for bringing this up!> The major drawback in sorting, is the need to parse DWARF, even a little bit > of it (only the first 4 bytes of a section to tell which version it is - first 12 if you > want to 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.Parsing the sections is one possible approach. Another way, maybe an even more "linkish", would be to check relocations that point to the input sections. If all of them are 64-bit, the section can be placed after ones targeted by 32-bit relocations. Checking relocations is probably slower, but the approach may be generalized for other situations, if necessary.> I do worry about slowing down general debug links so a "debug info > sorting" option may make sense, or it may not be worth it after measuring > the speed difference.The idea is to do nothing if the size of each output debug section is less than 4GiB. Thus, a noticeable linking speed degradation will exist only for projects which would most probably just fail to link otherwise. Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc.
James Henderson via llvm-dev
2020-Nov-11 08:57 UTC
[llvm-dev] [LLD] Support DWARF64, debug_info "sorting"
(Igor - I don't know what happened, but your email split the mail thread in gmail for me.) On Wed, 11 Nov 2020 at 08:50, Igor Kudrin <ikudrin at accesssoftek.com> wrote:> Thanks Alexander for bringing this up! > > > The major drawback in sorting, is the need to parse DWARF, even a little > bit > > of it (only the first 4 bytes of a section to tell which version it is - > first 12 if you > > want to 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. > > Parsing the sections is one possible approach. Another way, maybe an even > more "linkish", would be to check relocations that point to the input > sections. If all of them are 64-bit, the section can be placed after ones > targeted by 32-bit relocations. Checking relocations is probably slower, > but the approach may be generalized for other situations, if necessary. > > > I do worry about slowing down general debug links so a "debug info > > sorting" option may make sense, or it may not be worth it after measuring > > the speed difference. > > The idea is to do nothing if the size of each output debug section is less > than 4GiB. Thus, a noticeable linking speed degradation will exist only for > projects which would most probably just fail to link otherwise. > > Best Regards, > Igor Kudrin > C++ Developer, Access Softek, Inc. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201111/a0fdd37f/attachment.html>