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

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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201111/96a5d003/attachment.html>

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>

+James for context too (always good to include the folks from the
original threads for continuity)

Yeah, my general attitude there was just twofold, one that the
discussion had strayed fairly far from the review (so interested
parties might not see it, both because it's a targeted review thread
on the noisy llvm-commits, and because fo the title not having much
connection to the discussion) and it seemed to be somewhat
abstract/general - and there's a balance there. "We should do this
because I need it" (we shouldn't be implementing features for
especially niche use cases/if they don't generalize) isn't always a
compelling motivation but "we should do this because someone might
need it" isn't either (we shouldn't be implementing features that
have
no users).

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.

On Tue, Nov 10, 2020 at 9:30 PM Eric Christopher via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> 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 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev