How to sort mixed DWARF32 and DWARF64 .debug_*

[Fangrui Song]

On Wed, Nov 11, 2020 at 1:12 AM Fangrui Song <i@maskray.me> wrote:
>
> I want to bring it to your attention that on llvm-dev some folks are discussing
> how to sort mixed DWARF32 and DWARF64 .debug_* sections https://lists.llvm.org/pipermail/llvm-dev/2020-November/146522.html
>
> There are merits placing DWARF32 .debug_info before DWARF64 .debug_info
> because otherwise the DWARF32 .debug_info could still lead to out-of-range
> relocations. This approach will however break the usual rule for linking
> unrecognized sections:
>
>    "When not otherwise constrained, sections should be emitted in input order."
>
> https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html
> has an idea that DWARF64 sections can be detected by the relocation type (i.e.
> on ppc64, check whether the first relocation is R_PPC64_ADDR64)

Let me rephrase the problem:
If a .debug_* output section S can be larger than 32-bit and its section
offset is referenced by a DWARF32 input section of itself or another
.debug_* output section,
the relocation may be subject to 32-bit relocation overflow. If we
place such DWARF32
sections before DWARF64 sections, we can mitigate overflows in many cases.

(We can imagine that for a known large project, most compilation units
are DWARF64.
Some archives may have DWARF32 debug info and may be difficult to rebuild.
This partition scheme can solve the problems.)

I've been thinking about adding a linker option
--dwarf32-before-dwarf64 to partition DWARF32 input sections and
DWARF64 input sections.
I have a prototype for LLD: https://reviews.llvm.org/D91404 and there
is more description there.
Does such an option --dwarf32-before-dwarf64 look good to binutils folks?
I'd be happy to act as a bridge communicating thoughts from both sides:)

The option is not a -z one because it is not ELF specific.