[I sent the following to disc...@x86-64.org. I'm repeating it here,
because
the unwind program header has applicability beyond the amd64 abi.]
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:
> 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.
... but I have the same feeling. There's not much sense in codifying contradictions to reality, nor is there for disrupting reality to follow a spec for minor issues like this.
On Feb 25, 4:25 pm, Ali Bahrami <Ali.Bahr...@Sun.COM> wrote:
> 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:
Evandro Menezes wrote: > On Feb 25, 4:25 pm, Ali Bahrami <Ali.Bahr...@Sun.COM> wrote: >> 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:
> I don't see a problem with it off-hand, since possibly only Solaris > has used PT_SUNW_UNWIND. What value does Sun Studio for Linux use > though?
> Thanks.
Program headers are produced by the link-editor (ld). Sun Studio for Linux must be using the GNU ld, since the Solaris ld isn't available there, so the proper value for PT_GNU_EH_FRAME would be used.
>> 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.
> ... but I have the same feeling. There's not much sense in codifying > contradictions to reality, nor is there for disrupting reality to follow a > spec for minor issues like this.
>> If so, how would I go about getting that change made?
> I can make the change if there are no objections. I'll wait some time, a > week or two for other opinions to show up, remind me in two weeks > :)
> Ciao, > Michael.
It's been almost 2 weeks, and there were no objections, so I'd like to move forward with this. Here is my proposed text for the amd64 ABI:
------------------------------------------------------- 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_EH_FRAME 0x6474e550
PT_SUNW_EH_FRAME is a new name in the Solaris OSABI namespace that has the original ABI mandated value of 0x6474e550. The name follows the pattern set by PT_GNU_EH_FRAME.
The Solaris link-editor will continue to generate PT_SUNW_UNWIND for the reasons previously mentioned. However, the runtime linker will accept both SUNW values. I've already made these changes to Solaris, and will be integrating them within the next week or so. They should surface in OpenSolaris within a month or so.
|
