[llvm-dev] [LLD] Support DWARF64, debug_info "sorting"

[James Henderson via llvm-dev]

(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>