How to sort mixed DWARF32 and DWARF64 .debug_*

[Cary Coutant]

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

I went back and read through that thread, and now I get the impression
that this is a theoretical concern that no one has yet encountered in
practice. Am I wrong? If so, what sections have actually exceeded 4 GB
in size?

Looking at this analytically, the most likely section to exceed the
total size limit is .debug_info. There are only three places you could
have a relocatable reference into .debug_info:

(1) A reference from one DIE to another (external) DIE using
DW_FORM_ref_addr. This form should be rare, if present at all -- I
don't know of any mainstream use of this. It was intended to be used
in some kind of separate compilation where you have multiple
translation units for one compilation unit, or in some extreme forms
of global optimization. If this is in fact where you're encountering a
relocation overflow, you could (for the time being) simply invent your
own form DW_FORM_ref_addr8 and use it throughout your toolchain. That
could tide you over until we address this issue in DWARF 6.

(2) References from the .debug_names (or, in DWARF 4,
.debug_pubnames/pubtypes) table to a compilation unit. These
accelerated access tables are meant to be combined at link time, so
they could be generated as DWARF-64 tables when necessary.

(3) References from the .debug_aranges table to a compilation unit.
This may be the most likely failure scenario, where a .debug_aranges
section from a library is generated as DWARF-32, but references a
compilation unit whose offset within .debug_info is larger than 4 GB.
We could mitigate this by simply requiring that *all* .debug_aranges
tables be generated as DWARF-64. This would be a minimal impact, since
only the unit_length and debug_info_offset fields would grow; all the
range descriptor entries in the table would already be address-size.

All other relocatable values in DWARF using DW_FORM_sec_offset,
DW_FORM_strp, DW_FORM_ref_sup[48], DW_FORM_strp_sup, or
DW_FORM_line_strp refer to other DWARF sections, and those other
sections should be at least an order of magnitude smaller than
.debug_info. I suspect this is either a theoretical problem that could
wait, or something you could solve without any special linker support.

-cary