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

Wed Nov 18 10:34:43 PST 2020

My concern with using section type, is that it does modify ELF format spec, and can break various tools that rely on this information. This sems somewhat of a heavy handed approach to solving this problem.

Alternatively, if we do want to go with something more official then just doing it in a linker using first reloc, why not use sh_info? Seems like it's made for providing an extra information for each section_type. In this case .debug_*.

With it we have a current behavior of using names which as far as I can tell the default for figuring out debug sections. If producer provides this extra information the linker can improve layout to help with debug sections overflows, if producer doesn't provide this information, then it's a current behavior which also adheres to DWARF spec that says if DWARF32 and DWARF64 the onus is on the user.

Alex
________________________________
From: Fāng-ruì Sòng <maskray at google.com>
Sent: Tuesday, November 17, 2020 4:49 PM
To: Igor Kudrin <ikudrin at accesssoftek.com>
Cc: David Blaikie <dblaikie at gmail.com>; Wenlei He <wenlei at fb.com>; Alexander Yermolovich <ayermolo at fb.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Robinson, Paul <paul.robinson at sony.com>; James Henderson <jh7370.2008 at my.bristol.ac.uk>; Eric Christopher <echristo at gmail.com>
Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting"

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