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

[Eric Christopher via llvm-dev]

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 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 LLD linker to arrange debug_info sections so that DWARF32 comes
> first, and DWARF64 after them. This way as long as DWARF32 sections don't
> themselves go over 4gigs, the final binary can contain debug information
> that exceeds 4gig. Which I think will be the common case.
>
> An alternative approach that was proposed by James Henderson is for build
> system to take care of it, and to use -u to enforce order.
>

+Fangrui Song <maskray at google.com> here for thread visibility

Of these two approaches I think that the linker sorting is probably the one
I'd go with for the reasons you list below - I'm particularly sympathetic
to not wanting the unintended consequences of using -u here :)

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.

Thanks for bringing this up on the list! :)

-eric


>
> As, I would imagine, most projects of scale are using configurable build
> system that pulls in all the various dependencies automatically in a
> multi-language environment. I think the alternative approach will be more
> fragile than modifying LLD as it relies on a more complex system, and each
> customer of LLD will have to implement this "sorting" in their own build
> systems. The use of -u also kind of abuses this flag, and might have
> unintended consequences. As was pointed out by Wen Lei.
> From overhead perspective we only need to access few bytes of DWARF to
> determine if it's 32 or 64 bits. Customers who need DWARF64, already accept
> the overhead that it entails.
>
> Any thoughts?
>
> Thank You
> Alex
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201111/55701210/attachment.html>