Issue with small struct return values

Issue with small struct return values

[Andy Johnson]

Excerpt from the PPC SVR4 ABI:
---
Functions shall return float or double values in f1, with float values rounded to single
precision. Functions shall return values of type int, long, enum, short, and char, or a
pointer to any type as unsigned or signed integers as appropriate, zero- or sign-extended
to 32 bits if necessary, in r3. A structure or union whose size is less than or equal to 8
bytes shall be returned in r3 and r4, as if it were first stored in an 8-byte aligned memory
area and then the low-addressed word were loaded into r3 and the high-addressed word
into r4. Bits beyond the last member of the structure or union are not defined.
---

The GCC compiler for powerpc-sysv (or any variant except powerpc-solaris) is not
doing this.  Instead, it always passes a pointer to a receiving struct area in r3, regardless
of its size.  We are trying to support two different compilers on our system, one being
GCC and the other being a commercial compiler (which comes as part of a larger
IDE which we would like to offer to our users), which claims to support the PPC
EABI.  The commercial compiler is using the r3,r4 convention, which means that it
cannot use the div or ldiv library routines which have been built using the GCC compiler
(or any other library entry points which return small structs).

I would claim that the GCC compiler is not in conformance with the SVR4 ABI, even
though it claims to support it.  Have other users encountered this situation?  Is there
any thought about bringing GCC in line with the SVR4 ABI requirement?  Among
other things, it would make the code run faster, especially with optimization enabled.

Obviously, such a change would require a complete re-build of all binary files built
with GCC, regardless of the language being translated, since both caller sites and
callee sites involving small structs (<= 8 bytes) would be affected.

-AndyJ
--
E. Andrew Johnson               Tel: 978-256-0052 x1482
Mercury Computer Systems        Fax: 978-244-0520
199 Riverneck Road              andyj@mc.com
Chelmsford, MA 01824-2820       http://www.ma.ultranet.com/~andyjnsn


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi Andy,

Did anyone actually get back to you on this issue?

I think people knew about this inconsistency but did not push matters.
AFAIK, the gcc toolchain for ppc has always ignored that part of the abi.

As you say this would impact everything and require a complete re-compile of
all apps.  It would also be interesting to see whether checking for the size
of returned structures in order to know how to properly return the strucutre
actually impacts performance.  Also code that invokes methods/functions
dynamically used to implement native interfaces and  external object
interfaces would have to be rewritten.  This includes Mozilla, Java JDK,
OpenOffice, etc...

For what it is worth, I have found out that the abis implemented by PPC BSD,
MacOSX, IBM, and PPC Linux all differ in strange ways (even Mac OSX ABI is
not identical to IBM's EABI on which it was based).  So in the long run, I am
not sure that this issue matters.

Please let the linuxppc-dev list know what you find out officially from the
GNU folks (Geoff Keating, Franz Sirl, etc) about this issue.  It would be
interesting to know if we are going through yet again another complete binary
incompatible change!

Kevin


On Friday 19 January 2001 17:14, Andy Johnson wrote:
> Excerpt from the PPC SVR4 ABI:
> ---
> Functions shall return float or double values in f1, with float values
rounded to single
> precision. Functions shall return values of type int, long, enum, short,
and char, or a
> pointer to any type as unsigned or signed integers as appropriate, zero- or
sign-extended
> to 32 bits if necessary, in r3. A structure or union whose size is less
than or equal to 8
> bytes shall be returned in r3 and r4, as if it were first stored in an
8-byte aligned memory
> area and then the low-addressed word were loaded into r3 and the
high-addressed word
> into r4. Bits beyond the last member of the structure or union are not
defined.
> ---
>
> The GCC compiler for powerpc-sysv (or any variant except powerpc-solaris)
is not
> doing this.  Instead, it always passes a pointer to a receiving struct area
in r3, regardless
> of its size.  We are trying to support two different compilers on our
system, one being
> GCC and the other being a commercial compiler (which comes as part of a
larger
> IDE which we would like to offer to our users), which claims to support the
PPC
> EABI.  The commercial compiler is using the r3,r4 convention, which means
that it
> cannot use the div or ldiv library routines which have been built using the
GCC compiler
> (or any other library entry points which return small structs).
>
> I would claim that the GCC compiler is not in conformance with the SVR4
ABI, even
> though it claims to support it.  Have other users encountered this
situation?  Is there
> any thought about bringing GCC in line with the SVR4 ABI requirement?  Among
> other things, it would make the code run faster, especially with
optimization enabled.
>
> Obviously, such a change would require a complete re-build of all binary
files built
> with GCC, regardless of the language being translated, since both caller
sites and
> callee sites involving small structs (<= 8 bytes) would be affected.
>
> -AndyJ
> --
> E. Andrew Johnson               Tel: 978-256-0052 x1482
> Mercury Computer Systems        Fax: 978-244-0520
> 199 Riverneck Road              andyj@mc.com
> Chelmsford, MA 01824-2820       http://www.ma.ultranet.com/~andyjnsn
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

>>>>> "Kevin B Hendricks" writes:

Kevin> Did anyone actually get back to you on this issue?

	Geoff and I discussed the issue with Andy previously and we
suggested that he post a message to these lists.

Kevin> I think people knew about this inconsistency but did not push matters.
Kevin> AFAIK, the gcc toolchain for ppc has always ignored that part of the abi.

	IBM wants GCC (and therefore PowerPC Linux) to follow the SVR4 ABI
as written.  GCC should not be inventing new ABIs when perfectly good and
correct ABIs exist.  The longer this is allowed to continue, the harder it
is to correct.

	GCC 3.0 (whose major number implies breaking backward
compatibility) seems like a good opportunity to correct this mistake.

Kevin> For what it is worth, I have found out that the abis implemented by PPC BSD,
Kevin> MacOSX, IBM, and PPC Linux all differ in strange ways (even Mac OSX ABI is
Kevin> not identical to IBM's EABI on which it was based).  So in the long run, I am
Kevin> not sure that this issue matters.

	Neither IBM (AIX PowerOpen ABI?) nor MacOSX are based on the eABI.
Yes, they differ, but that is because they are different ABIs.  The Mac
PowerPC ABI is based on the IBM PowerOpen ABI.

	This issue does matter because this mistake harms PowerPC
performance on these systems, and because other commercial compilers
implement the ABI correctly which causes this GCC mistake to interfere
with interoperability.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi,

> 	Neither IBM (AIX PowerOpen ABI?) nor MacOSX are based on the eABI.
> Yes, they differ, but that is because they are different ABIs.  The Mac
> PowerPC ABI is based on the IBM PowerOpen ABI.
>

Just for the record, according to the Darwin dev list when I posted my
question about ABI's to them they said they have minor differences from even
the IBM PowerOpenABI (my mistake...I called this the EABI) and pointed myeto
some MacOSX only abi docs.

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi,

> 	GCC 3.0 (whose major number implies breaking backward
> compatibility) seems like a good opportunity to correct this mistake.

>From what I understand, GCC 3.0 would only have broken things for C++ based
items and not for everything.

So what you are proposing is a very major change!

I think during such a change, one other issue really should be addressed
(and I am sure there are others)

Given the ppc sys v abi uniqueness in handling varargs, there is no
cross-platform solution for passing the address of a va_list or dereferencing
that same beast.  Right now real programs do this (the JDK for example) and
there are no macros (like VA_COPY) that hide the differences.  This
introduces bugs that are very hard to track down.

Can you push something (a MACRO of some sort) like that through during the
GCC change David?

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

	GCC does not have control over how varargs are suppose to be
accessed -- that is part of the C language spec.

	Proposing an extension to GCC is a lot more difficult than having
GCC follow the ABI as written.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi David,

> 	Proposing an extension to GCC is a lot more difficult than having
> GCC follow the ABI as written.

Whose decision will this be?  Is this going to be a community based decision
or will gcc decide to do this unlaterally with or without the community's
support?

What voice should the currently shipping distributions have in this?

I saw no discussion on gcc-bugs about this issue (and was not privy to your
and Geoff's previuous discussion with Andy about this issue).

That is why I responded to Andy in the first place.

What process, if any exists for this decision to be made?

I assume you wanted a community based decision since you asked Andy to cc
this to the linuxppc dev list.

Also, on a more technical note, how many <= 8 byte structures are there in
actual use anyway?  I would guess that most uninos are less than or eqaul to
8 bytes and so returning unions would change.  So according to the abi, would
we would passing a union in to a function via a pointer but returning one in
registers?

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

	If you want an extension, propose it on the gcc mailinglist, or
better yet implement it and post it to gcc-patches mailinglist.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi David,

On Saturday 20 January 2001 21:02, David Edelsohn wrote:
> If you want an extension, propose it on the gcc mailinglist, or
> better yet implement it and post it to gcc-patches mailinglist.

That wasn't what I asked.  I asked what the process would be for making this
decision (if it has already not been made).

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

>>>>> "Kevin B Hendricks" writes:

Kevin> That wasn't what I asked.  I asked what the process would be for making this
Kevin> decision (if it has already not been made).

	Actually, it is the answer.  The decision would be made by the
developers if there was a good argument for it and/or a proposed
implementation.  The GCC SC might make the final decision, guided by the
public discussion.  The main issue with GCC extensions is that they be
well-defined so that we avoid the repeat of problems that have occurred
with previous extensions.

	What ever is proposed will not be included in GCC 3.0 because that
release has been frozen with respect to new features.

David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi,

Forgive my stupidity here.  Exactly what are you referring to as the
extension / new feature.  Do developers need to propse an extension to keep
the status quo or does Andy/you/IBM need to propose something to get the
change in.

> 	What ever is proposed will not be included in GCC 3.0 because that
> release has been frozen with respect to new features.

Please don't get me wrong.  I am not against the change.  I would like access
to as much ppc based commercial software as possible (it would be nice if IBM
released their JDK for PPC Linux with your nice JIT) and put me out of
business.  Apple will never release the Hotspot source to PPC Linux (I have
asked) and I hate re-inventing the wheel (and I can't read x86 assembler to
boot! so porting Hotspot will be a long term project for me at best).

I just want to understand the process of making this change to make sure we
don't create more hardship (financial and otherwise) for the few ppc linux
distributions out there as it is.  I think the timing of the change would be
important for YellowDogLinux, LinuxPPC, Debian, and SuSE (forgive me if I
left anyone out) to have a say in.

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

	You asked about a stdarg extension.  That is what I have been
discussing.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Kevin B. Hendricks]

Hi,

Boy are we on different pages!

On Saturday 20 January 2001 21:45, David Edelsohn wrote:
> You asked about a stdarg extension.  That is what I have been
> discussing.
>

I thought you said that vararg changes were C standards issues and not GCC
issues.

So I have been asking about the process of the ABI change since you said you
could not impact on the decision to add a MACRO to hide our unique varargs.
I never wanted to change the varargs, I wanted a macro to hide passing
pointers and dereferencing va_lists.

It would make no sense to break the abi on vararg passing and then support
a change on returning small structures to support the abi.

I am interested in the process of if and when the abi change will be made
that Andy wants to make myself clearer.  Can you shed some light on this?

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

>>>>> "Kevin B Hendricks" writes:

Kevin> I am interested in the process of if and when the abi change will be made
Kevin> that Andy wants to make myself clearer.  Can you shed some light on this?

	That is why this proposal was announced on this mailinglist.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[Brad Parker]

David Edelsohn wrote:
>	This issue does matter because this mistake harms PowerPC
>performance on these systems, and because other commercial compilers
>implement the ABI correctly which causes this GCC mistake to interfere
>with interoperability.

translation?  object files from ibm's c compiler won't work when linked
with object files from gcc...

who's ox are we stabbing here?  :-)

-brad


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Issue with small struct return values

[David Edelsohn]

>>>>> Brad Parker writes:

Brad> translation?  object files from ibm's c compiler won't work when linked
Brad> with object files from gcc...

Brad> who's ox are we stabbing here?  :-)

	If you were not being such a cynic, you might realize that there
are other vendors with commercial SysV and eABI compilers for PowerPC.
GCC does not work with any of the others, or people who hand-code assembly
for the ABI, like JITs.

	I guess that PowerPC Linux does not want to use anyone else's
commercial software.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/