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

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

On 2020-11-14, Alexander Yermolovich wrote:
>Thanks for doing a diff and asking in other groups.
>
>So if I understand your concern with using first reloc as it relates to .debug_str.
>
>In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, or R_X86_64_64, depending on DWARF format.
>
>A situation we might have is that an input .debug_info section is DWARF32 so it gets ordered apropriatly within output .debug_info section, but the input .debug_str section can be put in the output .debug_str section that is above 4GB. In which case we still hit overflow. So we also need to oder the .debug_str section, except in DWARF4 there is no real clear link, besides looking through .debug_info relocs.

Yes. For most other .debug_*, we can check whether the section has an 64-bit
absolute relocation to decide whether it is DWARF64. .debug_str is different in
that we need to check relocations referencing it. This makes its behavior
dependent on other sections, which is why I feel lost with the relocation
approach: when we write .debug_str 0 : { *(.debug_str) }, we really want the
output section .debug_str can be made up with just information from the input
section descriptions, not random information from other .debug_*

LLD -O1 (default) and GNU ld -O0 enable constant string merge within
SHF_MERGE&&SHF_STRINGS sections.  We need to pay attention as if a DWARF32
string gets folded into a DWARF64 string, the section referencing the DWARF32
string can still trigger a relocation overflow.

If we order DWARF32 components before DWARF64 components, with the
llvm::StringTableBuilder usage in LLD, we can make sure DWARF64 strings can get
folded into DWARF32 strings, not the other way around.

>Is that a correct summary?
>
>Also I don't quite understand what the issue is with linker script.
>
>My understanding is that:
>
>.debug_str 0 : { *(.debug_str) }
>
>Just stays that all .debug_str input sections should go in to .debug_str output section. It doesn't really specify the ordering within the output .debug_str section.

There is an assumption that linkers concatenate input sections in input order,
which is required by the ELF specification.  There are options which can change
the semantics of `*`: --sort-section, (gold specific) --section-ordering-file,
(LLD specific) --symbol-ordering-file.  Like the other options, we should
justify the `*` ordering by assigning appropriate semantics.

>Thank You
>Alex