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

[Igor Kudrin via llvm-dev]

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 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?

-- 
Best Regards,
Igor Kudrin
C++ Developer, Access Softek, Inc.