Issue with small struct return values
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 [email protected] Chelmsford, MA 01824-2820 http://www.ma.ultranet.com/~andyjnsn
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
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
Quoted 3 lines · Andy Johnson
Excerpt from the PPC SVR4 ABI:
---
Functions shall return float or double values in f1, with float values
rounded to single
Quoted 1 line
precision. Functions shall return values of type int, long, enum, short,
and char, or a
Quoted 1 line
pointer to any type as unsigned or signed integers as appropriate, zero- or
sign-extended
Quoted 1 line
to 32 bits if necessary, in r3. A structure or union whose size is less
than or equal to 8
Quoted 1 line
bytes shall be returned in r3 and r4, as if it were first stored in an
8-byte aligned memory
Quoted 1 line
area and then the low-addressed word were loaded into r3 and the
high-addressed word
Quoted 1 line
into r4. Bits beyond the last member of the structure or union are not
defined.
Quoted 3 lines
---
The GCC compiler for powerpc-sysv (or any variant except powerpc-solaris)
is not
Quoted 1 line
doing this. Instead, it always passes a pointer to a receiving struct area
in r3, regardless
Quoted 1 line
of its size. We are trying to support two different compilers on our
system, one being
Quoted 1 line
GCC and the other being a commercial compiler (which comes as part of a
larger
Quoted 1 line
IDE which we would like to offer to our users), which claims to support the
PPC
Quoted 1 line
EABI. The commercial compiler is using the r3,r4 convention, which means
that it
Quoted 1 line
cannot use the div or ldiv library routines which have been built using the
GCC compiler
Quoted 3 lines
(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
Quoted 1 line
though it claims to support it. Have other users encountered this
situation? Is there
Quoted 2 lines
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.
Quoted 2 lines
Obviously, such a change would require a complete re-build of all binary
files built
Quoted 1 line
with GCC, regardless of the language being translated, since both caller
sites and
Quoted 10 lines
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 [email protected] Chelmsford, MA 01824-2820 http://www.ma.ultranet.com/~andyjnsn
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"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 [email protected] 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/
Hi,
Quoted 4 lines
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/
Hi,
Quoted 4 lines
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/
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/
Hi David,
Quoted 2 lines
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/
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/
Hi David,
Quoted 2 lines · 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.
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/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"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/
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.
Quoted 2 lines
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/
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/
Hi,
Boy are we on different pages!
Quoted 3 lines · David Edelsohn
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/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"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/
Quoted 4 lines · David Edelsohn
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/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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/