[PATCH] D87011: [DebugInfo] Add the -dwarf64 switch to llc and other internal tools (4/19).

[Alexander Yermolovich via Phabricator via llvm-commits]

ayermolo added a comment.

In D87011#2378533 <https://reviews.llvm.org/D87011#2378533>, @ikudrin wrote:

> In D87011#2378347 <https://reviews.llvm.org/D87011#2378347>, @jhenderson wrote:
>
>> At least in LLD, it's not quite as simple as being added after the user's code: if a library appears on the link line it will be included in the output order as soon as it is determined it is needed. Thus if you have have three modules 1.o, 2.o, and 3.o, with 3.o in an archive 3.a and 1.o requiring 3.o, you end up with an output order of `1.o 3.o 2.o` if the input order was `1.o 3.a 2.o` or `3.a 1.o 2.o` or an output order of `1.o 2.o 3.o` if the input order was `1.o 2.o 3.a`. In fact, with use of the --undefined linker switch, you can even force 3.o to appear first.
>>
>> I accept using --undefined or rearranging the command-line order is less than ideal, but I'm really not convinced LLD should have any place in parsing the DWARF to determine output order. Furthermore, it's not even a reliable solution - if the objects built with DWARF32 (potentially all of which might have come from libraries) are large enough, no amount of reordering will fix the behaviour. I think users who need DWARF64 in their libraries are just going to have to request DWARF64 versions of the libraries, if the --undefined and reordering command line options are insufficient.
>
> I'd guess that for a large-scale project the recommendation to use `-u` would be unrealistic. We are talking about projects where debugging information in a single section can easily go beyond the 4GiB limit; it is impossible for the developer to adjust the command line manually.
>
>> By the way, from a semantic point of view, I don't think it matters if the DWARF is in a different order to the data it represents - I'm just concerned about the maintenance and performance burden of having to parse the DWARF to achieve this reordering.
>
> There is no need to parse the debug info sections. Reading only the first 4 bytes of `.debug_info` is enough to assess the format (there might be input files with format intermixing, but we can ignore them in the sack of simplicity). And we do not need any automatic sorting if the size of an output section is less than 4GiB.

Exactly. Not to mention, I think for users that actually worry about 4Gig limit they have pretty complex build system that will need to be modified to get build order right. Probably doable, but looking at overall compilation pipeline, is it really the best approach? Within lld we don't have to parse entire debug section, just read few bytes in each CU to determine if it's 32 or 64 bit.
Yes theoretically it is possible that there are just so many third party libraries  that they will over flow 4gig by themselves, but I think common case is they will be under 4 gigs.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87011/new/

https://reviews.llvm.org/D87011