Solaris PT_SUNW_UNWIND is not in agreement with amd64 ABI

26 views
Skip to first unread message

Ali Bahrami

unread,
Feb 25, 2009, 5:25:10 PM2/25/09
to Generic System V Application Binary Interface
[I sent the following to dis...@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:

-------------------------------------------------------
- PT_SUNW_UNWIND 0x6474e550
+ PT_SUNW_UNWIND 0x6464e550
-------------------------------------------------------

If so, how would I go about getting that change made?

Thanks...

- Ali

Michael Matz

unread,
Feb 26, 2009, 7:11:18 AM2/26/09
to Generic System V Application Binary Interface
Hi,

On Wed, 25 Feb 2009, Ali Bahrami wrote:

> 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 */

Hmm, unfortunate ...

> 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.

> -------------------------------------------------------
> - PT_SUNW_UNWIND 0x6474e550
> + PT_SUNW_UNWIND 0x6464e550
> -------------------------------------------------------
>
> 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.

Evandro Menezes

unread,
Feb 26, 2009, 11:00:48 AM2/26/09
to Generic System V Application Binary Interface
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:
>
>     -------------------------------------------------------
> -                     PT_SUNW_UNWIND             0x6474e550
> +                     PT_SUNW_UNWIND             0x6464e550
>     -------------------------------------------------------

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.

Ali Bahrami

unread,
Feb 26, 2009, 11:16:19 AM2/26/09
to gener...@googlegroups.com

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.

- Ali

Ali Bahrami

unread,
Mar 10, 2009, 2:38:27 PM3/10/09
to gener...@googlegroups.com

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_UNWIND 0x6464e550
-------------------------------------------------------

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.

Thanks for your help.

- Ali

Michael Matz

unread,
Mar 11, 2009, 6:28:50 AM3/11/09
to gener...@googlegroups.com
Hi,

On Tue, 10 Mar 2009, Ali Bahrami wrote:

> It's been almost 2 weeks, and there were no objections, so
> I'd like to move forward with this.

Committed as r219. I'll see if I can somehow trigger building the pdf on
the webpage. It keeps breaking :-/


Ciao,
Michael.

Reply all
Reply to author
Forward
0 new messages