While examining some objects yesterday, I discovered that Solaris
uses the wrong value for the PT_SUNW_UNWIND program header. By wrong,
I mean only that it's not the value specified by the amd64 ABI. Everything
works fine --- there's no need to be alarmed... :-)
I sent mail about the subject to a couple of ABI-related lists:
generic-abi at googlegroups.com
discuss at x86-64.org
I thought that it might be of interest to some readers on this list
as well --- the message I sent is below. Basically, I'm proposing to
change the documentation (amd64 ABI) rather than the code, since there's
not much real-world benefit to changing this now.
- Ali
--------------------------------------------------------------------------
I work on the Solaris linkers, and have encountered
an amd64 ABI compliance issue that I need to resolve.
I was comparing Linux and Solaris amd64 objects yesterday,
and discovered that Solaris is using the wrong value for
PT_SUNW_UNWIND! The ABI says this:
-------------------------------------------------------
5.1.1 Program header
The following AMD64 program header types are defined:
Table 5.1: Program Header Types
Name Value
PT_GNU_EH_FRAME 0x6474e550
PT_SUNW_UNWIND 0x6474e550
PT_GNU_EH_FRAME and PT_SUNW_UNWIND The segment contains the
stack unwind tables. See Section 4.2.4 of this document.
-------------------------------------------------------
GNU and Sun are supposed to use the same value, but are allowed
their own names for it.
However, the value actually used by Solaris, defined in
/usr/include/sys/elf.h, is different:
#define PT_SUNW_UNWIND 0x6464e550 /* amd64 UNWIND program header */
It appears that this is nothing more than an unfortunate typo, made in
October 2004, and subsequently released in Solaris 10, our first
release with amd64 support. So, now, there exist 4+ years of Solaris objects
with this value embedded in them, all of which work properly. There has never
been a Solaris object that used the ABI-mandated value.
It is of course possible for us to change Solaris to use the ABI
mandated value. Since we have existing objects in the field, we'll end
up having to support both values forever, which is ugly, and which
offers little benefit to the Solaris community, or to the wider amd64
community.
Instead, I wonder if there would be an objection to changing the
amd64 ABI to simply codify what has already happened. Although it
isn't ideal, I think this solution is the least disruptive way
forward from the place we now find ourselves. Using context diff
style markings, the text quoted above would then become:
-------------------------------------------------------
- PT_SUNW_UNWIND 0x6474e550
+ PT_SUNW_UNWIND 0x6464e550
-------------------------------------------------------
If so, how would I go about getting that change made?
Thanks...
- Ali
