How to sort mixed DWARF32 and DWARF64 .debug_*

[Cary Coutant]

> >I think that the DWARF spec made a mistake in not specifying
> >DW_FORM_sec_offset and DW_FORM_ref_addr to be address-sized values
> >rather than dependent on DWARF-32 vs. DWARF-64. That would blow up all
> >DWARF attributes of form DW_FORM_sec_offset, but that can be mitigated
> >by using DW_FORM_strx, DW_FORM_loclistx, and DW_FORM_rnglistx wherever
> >possible. DW_FORM_ref_addr should be pretty rare.
> >
> >I would move to fix this in DWARF 6.
>
> DW_FORM_strp/DW_strp_sup/DW_FORM_line_strp/DW_FORM_sec_offset and
> DW_FORM_GNU_ref_alt/DW_FORM_GNU_strp_alt also use 32-bit offsets in the
> 32-bit DWARF format. Didn't they intentionally use 32-bit offsets to
> avoid unneeded size bloat?

Probably. That's why I wouldn't want to change DW_FORM_strp, et al. To
allow for a string table, range list table, and address table that can
grow larger than 4GB, I'd use DW_FORM_strx and the other indirect
forms introduced in DWARF 5. We'd also have to change the
.debug_str_offsets section to use address-sized entries (and add an
address_size field to the section header).

> >Until that's available, though, it looks like we still need a fix....
> >
> >> SHT_DWARF64    19
> >
> >I'd prefer not to add a new section type, but I have an alternate
> >suggestion: Use a new section flag, say SHF_LARGE, that would tell the
> >linker that these section contributions should be placed after all
> >other contributions. X86 already has such a flag, SHF_X86_64_LARGE,
> >and PA-RISC and Itanium have the opposite -- SHF_PARISC_SHORT and
> >SHF_IA_64_SHORT.
>
> Does SHF_LARGE add a built-in section ordering rule within
> an input section description (e.g. *(.foo))?

In this case, it would. In the precedents I mentioned, the flag
applies to the section as a whole, rather than its parts; on PA-RISC
and Itanium, for example, we have a .sdata section with SHF_xxx_SHORT,
which is automatically placed close to gp.

> (A precedent of a section flag altering ordering is SHF_LINK_ORDER: https://sourceware.org/bugzilla/show_bug.cgi?id=26256)

Yes, this would be incompatible with SHF_LINK_ORDER.

> I can see a merit using SHF_LARGE. If we have other non-SHF_ALLOC
> sections which need section offset references (.long or .quad), the flag
> can help them as well as .debug_*. Currently there is no such a need, though.
>
> Looking at SHF_X86_64_LARGE, it does not seem to need special input
> section ordering as it seems to always use different output section names (.lbss/.ldata/.lrodata)
> (The flag is undocumented as far as I can tell)
>
>    commit 3b22753a67cf616514de804ef6d5ed5e90a7d883
>    Author: H.J. Lu <hjl.tools@gmail.com>
>    Date:   Mon Jul 25 08:41:08 2005
>
>        bfd/
>
> Could you describe a bit how SHF_IA_64_SHORT/SHF_PARISC_SHORT is used?

See above. The SHF_X86_64_LARGE flag is basically just the reverse of
what I described for .sdata on PA and Itanium.

-cary