How to sort mixed DWARF32 and DWARF64 .debug_*

[Cary Coutant]

[I'll post a copy of this message to the gABI list; let's keep the
discussion over there, so it's all in one place.]

-cary

On Tue, Nov 17, 2020 at 3:08 PM Cary Coutant <ccoutant@gmail.com> 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)
>
> 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