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

[Fāng-ruì Sòng via llvm-dev]

On 2020-11-17, Igor Kudrin wrote:
>
>On 17.11.2020 14:05, Fāng-ruì Sòng wrote:
>>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote:
>>>
>>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote:
>>>>For .debug_* in object files:
>>>>
>>>>DWARF32 -> SHT_PROGBITS (unchanged)
>>>>DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64
>>>>
>>>>In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If
>>>>all input sections are SHT_DWARF64, the output section type probably
>>>>should also be SHT_DWARF64.
>>>>If mixed, SHT_PROGBITS.
>>>
>>>I am not really sure that we need a new section type. This gets a small
>>>simplification in one part of the linker but adds much more burden of
>>>supporting that to all tools and specs around. And that support would be
>>>required for a rarely used feature, which certainly results that support
>>>to be partial and sometimes erroneous.
>>
>>This is not a small simplification. If we consider how we would
>>address .debug_str with the relocation approach,
>>it would be quite contrived. A reply I just made
>>https://lists.llvm.org/pipermail/llvm-dev/2020-November/146673.html
>>detailed why I don't like the conceptual model: the behavior is
>>dependent on other sections.
>
>I do not see real issues in the dependency on other sections. Section 
>7.4, p. 198, DWARFv5 states: "The 32-bit and 64-bit DWARF format 
>conventions must not be intermixed within a single compilation unit." 
>From this, we can conclude that if a ".debug_info" section contains 
>only 64-bit relocations, all other debug info sections in the object 
>file are in the 64-bit DWARF format. This can be simplified to 
>checking just the first relocation of this section, as you have made 
>in https://reviews.llvm.org/D91404, and then spreading the assessment 
>to all other debug sections in the object file. Sure, this heuristic 
>will not work for some clumsy partially linked relocatable objects 
>with a mixture of DWARF64 and DWARF32 data, but I guess they can be 
>ignored for the first shot, because, firstly, their creation is 
>usually under full control of the user and, secondly, the heuristic 
>can be extended to check all the relocations if that will be ever 
>necessary.

I don't like the "if .debug_info looks like DWARF64, mark .debug_str
approach" because it makes a section's behavior dependent on other
sections in the input file, diverging a lot from the current way
existing output section descriptions/input section descriptions are
handled. This is about system consistency that I care a lot and really
don't want to break giving that we have compelling alternative designs.

>>I also felt bad as I had to do string comparison on ".debug_"
>>(https://reviews.llvm.org/D91404)
>
>Well, that is a common way to find sections with debugging information, no?
>
>>I've chatted with gdb folks: gdb (gdb/dwarf2/read.c) is agnostic about
>>the section type. (They just cannot handle multiple .debug_info
>>sections.)
>>SHT_PROGBITS is a default (or "use this if nothing more specific
>>exists") section type that probably no tool will specifically check
>>the type.
>>For many tools, they don't understand DWARF64 yet - there is little
>>they need to adapt when they add DWARF64 support.
>>Currently the only problem I can think of is readelf -S (from my
>>understanding of
>>https://sourceware.org/pipermail/binutils/2020-November/114116.html ,
>>Nick will be happy if I write a GNU readelf patch to make the section
>>header table dump look good:) )
>
>My main concern is that the new type is mostly useless for everyone, 
>except that it provides a small hint for the linker, which is not very 
>important because the same information can be easily and reliably 
>gathered in place. Is that hint really so useful that deserves special 
>support on the ELF specs level?

It is not useless. Avoiding string comparison on ".debug_" is one thing
(sometimes this can improve performance a bit). The linker complexity is
another. As I mentioned in my previous reply, "SHT_PROGBITS+SHT_DWARF64
=> SHT_DWARF64" makes the scheme automatically work with relocatable links.

There are 0x60000000 generic section type values and 0x10000000 OS
specific values. The resource is abundant.

On https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ , Cary Coutant
has made an alternative proposal by adding a new section flag.
Personally I prefer a section type a section flag with reasons explained
by Ali Bahrami. People are still arguing but I appreciate that the theme
of the discussion is that people acknowledge the use cases and agree to
use an appropriate ELF-level thing, instead of adding ad-hoc rules to
the linker.