How to sort mixed DWARF32 and DWARF64 .debug_*

[Fangrui Song]

On 2020-11-17, Cary Coutant wrote:
>I replied in the gABI group...
>
>>> It seems that they are intermixable by design, but that the
>>> design is incomplete. I read this as saying "we don't care
>>> if you mix this content, but the linkers might, and that's
>>> not our problem". I think you're right that we could just
>>> reject such a link, but it's also clear that the end user
>>> won't understand these subtleties, and will simply blame
>>> the component that issues the error. That's fine if the
>>> number of cases is small, but at some point, it does become
>>> a linking problem that wants solving.
>
>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?

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

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

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?