Follow-up: Mixed DWARF32/DWARF64 section ordering in ELF

[刘可]

Hi,

I’d like to follow up on the 2020 discussion, “Reserve a section type value for DWARF64”:

https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ/m/Qq8-76noAwAJ

The same problem has come up again in current LLVM/LLD work. When DWARF32 and DWARF64 input sections are mixed, a DWARF32 contribution may be placed at a high offset and cause relocation overflow.

We are looking for an ELF-level producer/linker contract that allows the linker to order these contributions without parsing DWARF contents. The appropriate representation and scope are still open questions; the mechanism may need to apply beyond .debug_*, for example to .eh_frame.

The current LLVM RFC is here:

https://discourse.llvm.org/t/rfc-use-sht-dwarf64-for-lld-dwarf32-dwarf64-debug-section-ordering/91190

Before proceeding with an implementation, I would appreciate guidance on:

• whether this problem warrants a generic ELF ABI extension;

• what representation and semantics would be appropriate;

• how such a mechanism should remain compatible with existing linkers and consumers.

Thanks.

[Cary Coutant]

This is a timely reminder, now that we (the DWARF committee) are actively working on DWARF 6. We've already made a step in this direction, with Issues 211101.1 and 240320.1, which permit limited mixing of DWARF-32 and DWARF-64 sections, but that's not enough. What we really need is to fix DWARF so that a DWARF-32 section contribution is always able to reference any other DWARF-32 contributions from the same CU regardless of the link-time layout. The solutions proposed here in the gABI group really only address the problem halfway—they will still fail if the total accumulated size of DWARF-32 contributions exceeds 4 GB.

I'm working on a new proposal to fix this. The basic idea is to make sure that all inter-section references in a DWARF-32 CU can reach beyond the 4 GB limit. Rather than blowing up all such inter-section references to use 8-byte section offsets, however, we'll expand on the concepts introduced for split DWARF (in DWARF 5), where each CU declares a base offset to each related section, and individual references to those related sections can use 32-bit offsets relative to that base. With split DWARF, we added base offsets for a few related sections, but we'd need to add a few more. We'll also need a new form code that allows us to put an 8-byte section offset in a DWARF-32 CU. There are a few other places where we'll need to expand 32-bit offsets to 64-bit offsets in a DWARF-32 CU, but the base+offset idea can take care of most of the cases that would otherwise lead to excessive expansion of the DWARF.

The goal is to make it possible to compile with DWARF-32 everywhere, except for a minimal number of pathological CUs that would exceed the 4 GB limit on their own. It should not be necessary to switch an entire build to DWARF-64.

In the meantime, I would suggest using the ".debug64_*" section naming convention, with linker scripts designed to link those into the corresponding 32-bit sections, but at the end. I'm still opposed to making any gABI changes for this, as I see them all as nothing better than a temporary half-baked solution.

-cary

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/generic-abi/a3912989-622a-4951-96dc-d2658cdaa4a6n%40googlegroups.com.

[Roland McGrath]

I concur that a DWARF solution to this DWARF linking issue is best, and that no ELF-level feature that has been proposed as a workaround has sufficient independent utility to be worthwhile.