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

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

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

> In D87011#2378224 <https://reviews.llvm.org/D87011#2378224>, @jhenderson wrote:
>
>> I wouldn't expect LLD to need to do anything specific for DWARF64 support. It should generally speaking be treating the sections as opaque, in my opinion, and treat them no differently to other sections. If a user is mixing DWARF32 and DWARF64, then I'd say it's on their heads if relocations can't reach (just the same as it is if they're using DWARF32 but really need DWARF64). Any interactions LLD does have with the contents of the DWARF sections should be controlled via the DebugInfo library, and therefore if that library works for DWARF64, LLD doesn't need any special handling.
>
> That would be true if there would be no third-party libraries a project might depend on. These libraries would have 32-bit debug info, which is the recommended option from the DWARF standard, as far as I can remember. And, in general, these libraries would be added to the link after the user's code, to satisfy dependencies.

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.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87011