[patch] powerpc libffi Net/FreeBSD

[patch] powerpc libffi Net/FreeBSD

[Andreas Tobler]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Hello,

I'd like to commit the attached patch to gcc-head.

The patch comes from:
http://sourceware.org/ml/libffi-discuss/2009/msg00069.html

I tested the patch on gcc-head, FreeBSD:

http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00132.html

I also tested it on ppc-linux to see that there is no impact on non BSD 
targets.

Ok for trunk?

Andrew, I will wait until you did the merge.

Thanks,

Andreas

2009-06-02  Wim Lewis  <wiml@hhhh.org>

	* src/powerpc/ffi.c: Avoid clobbering cr3 and cr4, which are
	supposed to be callee-saved.
	* src/powerpc/sysv.S (small_struct_return_value): Fix overrun of
	return buffer for odd-size structs.

[-- Attachment #2: small_struct_ppc.diff --]
[-- Type: text/plain, Size: 2888 bytes --]

Index: src/powerpc/ffi.c
===================================================================
--- src/powerpc/ffi.c	(revision 148063)
+++ src/powerpc/ffi.c	(working copy)
@@ -42,11 +42,12 @@
   FLAG_RETURNS_64BITS   = 1 << (31-28),
 
   FLAG_RETURNS_128BITS  = 1 << (31-27), /* cr6  */
-
-  FLAG_SYSV_SMST_R4     = 1 << (31-16), /* cr4, use r4 for FFI_SYSV 8 byte
+  FLAG_SYSV_SMST_R4     = 1 << (31-26), /* use r4 for FFI_SYSV 8 byte
 					   structs.  */
-  FLAG_SYSV_SMST_R3     = 1 << (31-15), /* cr3, use r3 for FFI_SYSV 4 byte
+  FLAG_SYSV_SMST_R3     = 1 << (31-25), /* use r3 for FFI_SYSV 4 byte
 					   structs.  */
+  /* Bits (31-24) through (31-19) store shift value for SMST */
+
   FLAG_ARG_NEEDS_COPY   = 1 << (31- 7),
   FLAG_FP_ARGUMENTS     = 1 << (31- 6), /* cr1.eq; specified by ABI */
   FLAG_4_GPR_ARGUMENTS  = 1 << (31- 5),
@@ -684,14 +685,14 @@
 	      if (size <= 4)
 		{
 		  flags |= FLAG_SYSV_SMST_R3;
-		  flags |= 8 * (4 - size) << 4;
+		  flags |= 8 * (4 - size) << 8;
 		  break;
 		}
 	      /* These structs are returned in r3 and r4. See above.   */
 	      if  (size <= 8)
 		{
-		  flags |= FLAG_SYSV_SMST_R4;
-		  flags |= 8 * (8 - size) << 4;
+		  flags |= FLAG_SYSV_SMST_R3 | FLAG_SYSV_SMST_R4;
+		  flags |= 8 * (8 - size) << 8;
 		  break;
 		}
 	    }
Index: src/powerpc/sysv.S
===================================================================
--- src/powerpc/sysv.S	(revision 148063)
+++ src/powerpc/sysv.S	(working copy)
@@ -135,30 +135,19 @@
 	b	L(done_return_value)
 
 L(small_struct_return_value):
-	mtcrf	0x10,%r31	/* cr3  */
-	bt-	15,L(smst_one_register)
-	mtcrf	0x08,%r31	/* cr4  */
-	bt-	16,L(smst_two_register)
-	b       L(done_return_value)
-
-L(smst_one_register):
-	rlwinm  %r5,%r31,5+23,32-5,31 /* Extract the value to shift.  */
-	slw	%r3,%r3,%r5
-	stw	%r3,0(%r30)
+	extrwi	%r6,%r31,2,19         /* number of bytes padding = shift/8 */
+	mtcrf	0x02,%r31	      /* copy flags to cr[24:27] (cr6) */
+	extrwi	%r5,%r31,5,19         /* r5 <- number of bits of padding */
+	subfic  %r6,%r6,4             /* r6 <- number of useful bytes in r3 */
+	bf-	25,L(done_return_value) /* struct in r3 ? if not, done. */
+/* smst_one_register: */
+	slw	%r3,%r3,%r5           /* Left-justify value in r3 */
+	mtxer	%r6                   /* move byte count to XER ... */
+	stswx	%r3,0,%r30            /* ... and store that many bytes */
+	bf+	26,L(done_return_value)  /* struct in r3:r4 ? */
+	add	%r6,%r6,%r30          /* adjust pointer */
+	stswi	%r4,%r6,4             /* store last four bytes */
 	b	L(done_return_value)
-L(smst_two_register):
-	rlwinm  %r5,%r31,5+23,32-5,31 /* Extract the value to shift.  */
-	cmpwi	%r5,0
-	subfic	%r9,%r5,32
-	slw	%r29,%r3,%r5
-	srw	%r9,%r4,%r9
-	beq-	L(smst_8byte)
-	or	%r3,%r9,%r29
-	slw	%r4,%r4,%r5
-L(smst_8byte):
-	stw	%r3,0(%r30)
-	stw	%r4,4(%r30)
-	b	L(done_return_value)
 
 .LFE1:
 END(ffi_call_SYSV)

Re: [patch] powerpc libffi Net/FreeBSD

[Dave Korn]

Andreas Tobler wrote:

> Ok for trunk?
> 
> Andrew, I will wait until you did the merge.

  We should probably institute a coding standard or other process to avoid
running into this kind of accidental fork again.  Perhaps we could even ask DJ
to extend his libiberty cross-checker to validate libffi for us as well?

    cheers,
      DaveK

Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Andrew Haley]

Dave Korn wrote:
> Andreas Tobler wrote:
> 
>> Ok for trunk?
>>
>> Andrew, I will wait until you did the merge.
> 
>   We should probably institute a coding standard or other process to avoid
> running into this kind of accidental fork again.  Perhaps we could even ask DJ
> to extend his libiberty cross-checker to validate libffi for us as well?

Maybe.  Even after my merge there will be some remaining differences.

*  Libtool differences

*  GPL v3 differences, unless we bump libffi to GPL v3 as well

My first wodge of changes will be only the substantive differences
in the library itself: later I'll get to the testsuite and the rest.
To begin with, I'm just going to update upstream libffi with the gcc
changes, and then see how much difference there is.  I'm guessing not
much.

Questions for Anthony Green:

1.  I don't understand the libffi version numbers.  Can you give
me any explanations?  It seems to be 3.0.8 upstream but 2.1 in gcc,
but this doesn't seem in any way to correspond with reality.

2.  What's with the ChangeLog.libffi and ChangeLog.libgcj files?

Thanks,
Andrew.

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Anthony Green]

Andrew Haley wrote:
>
> Questions for Anthony Green:
>
> 1.  I don't understand the libffi version numbers.  Can you give
> me any explanations?  It seems to be 3.0.8 upstream but 2.1 in gcc,
> but this doesn't seem in any way to correspond with reality.
>   
Configury like this just hasn't been merged back into GCC.   The version 
number in GCC is mostly irrelevant as GCC doesn't install libffi; it is 
simply incorporated in its entirety into libgcj.   Ideally the configury 
should be merged, but as you've no doubt discovered, this isn't a simple 
task.  If you think we should update selected parts of the configury in 
GCC then I can do that.

> 2.  What's with the ChangeLog.libffi and ChangeLog.libgcj files?
>
>   
ChangeLog.libgcj goes back to when libffi was first packaged with 
libgcj.   It shouldn't be used anymore.   See gcc/zlib/ChangeLog.gcj for 
something similar.

ChangeLog.libffi are changes that have been made manually to libffi 
outside of the GCC tree.  It's reasonable to delete entries from 
ChangeLog.libffi as they are committed to GCC and merged back into libffi.

AG

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Dave Korn]

Anthony Green wrote:
> Andrew Haley wrote:
>>
>> Questions for Anthony Green:
>>
>> 1.  I don't understand the libffi version numbers.  Can you give
>> me any explanations?  It seems to be 3.0.8 upstream but 2.1 in gcc,
>> but this doesn't seem in any way to correspond with reality.
>>   
> Configury like this just hasn't been merged back into GCC.   The version
> number in GCC is mostly irrelevant as GCC doesn't install libffi; it is
> simply incorporated in its entirety into libgcj.   

  It may not be supposed to, but GCC HEAD currently does (for me at any rate)
install $prefix/lib/libffi.{la,a}.

    cheers,
      DaveK

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Andrew Haley]

Dave Korn wrote:
> Anthony Green wrote:
>> Andrew Haley wrote:
>>> Questions for Anthony Green:
>>>
>>> 1.  I don't understand the libffi version numbers.  Can you give
>>> me any explanations?  It seems to be 3.0.8 upstream but 2.1 in gcc,
>>> but this doesn't seem in any way to correspond with reality.
>>>   
>> Configury like this just hasn't been merged back into GCC.   The version
>> number in GCC is mostly irrelevant as GCC doesn't install libffi; it is
>> simply incorporated in its entirety into libgcj.   
> 
>   It may not be supposed to, but GCC HEAD currently does (for me at any rate)
> install $prefix/lib/libffi.{la,a}.

Yes, I agree.  Installing libffi is deliberate.

Andrew.

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Eric Botcazou]

> Configury like this just hasn't been merged back into GCC.   The version
> number in GCC is mostly irrelevant as GCC doesn't install libffi; it is
> simply incorporated in its entirety into libgcj.

It does, since GCC 3.x at least.

-- 
Eric Botcazou

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Andrew Haley]

The gcc -> libffi merge is done.

Now I'm doing libffi -> gcc.

Andrew.

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Jack Howarth]

On Wed, Jun 03, 2009 at 10:39:56AM +0100, Andrew Haley wrote:
> 
> My first wodge of changes will be only the substantive differences
> in the library itself: later I'll get to the testsuite and the rest.
> To begin with, I'm just going to update upstream libffi with the gcc
> changes, and then see how much difference there is.  I'm guessing not
> much.
> 
> Questions for Anthony Green:
> 
> 1.  I don't understand the libffi version numbers.  Can you give
> me any explanations?  It seems to be 3.0.8 upstream but 2.1 in gcc,
> but this doesn't seem in any way to correspond with reality.
> 
> 2.  What's with the ChangeLog.libffi and ChangeLog.libgcj files?
> 
> Thanks,
> Andrew.

Andrew,
    Has there been any code exchange between the upstream libffi and
the forked libffi that PyObjC uses? I was told the following by Bill Bumgarner
at Apple a couple years back....

>> So... long story short.
>>
>> About 10 years ago, PyObjC forked libffi for use in the PyObjC
>> project.  I don't remember exactly why it was forked, but forked it was.
>>
>> The PyOBjC version of libffi has been maintained over the years,
>> specifically targeted to Mac OS X.   In the past year, it got quite a
>> bit of attention both to support the 64 bit variants of Mac OS X and
>> quite a bit of cleanup work (new testing infrastructure, man pages,
>> etc.etc.etc).   It also grew an Xcode project.
>> 
>> I would be perfectly happy to see all the changes folded back into the
>> FSF/GCC community version (as long as the license remains liberal --
>> but we can fork it at the point of change, if it ever changes) and no
>> longer have a forked version for PyObjC.
>>
>> But none of us have the time to fold together the decade+ of forked
>> development.    At this point, the most likely path forward is to drop
>> the PyObjC version of FFI back into the PyObjC repository.   It will,
>> at least, be widely accessible again.
>>
>> b.bum

...regarding the origin of the files at...

 http://www.opensource.apple.com/darwinsource/10.5/libffi-10/

                               Jack

Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]

[Andrew Haley]

Jack Howarth wrote:
> On Wed, Jun 03, 2009 at 10:39:56AM +0100, Andrew Haley wrote:
>> My first wodge of changes will be only the substantive differences
>> in the library itself: later I'll get to the testsuite and the rest.
>> To begin with, I'm just going to update upstream libffi with the gcc
>> changes, and then see how much difference there is.  I'm guessing not
>> much.
>>
>> Questions for Anthony Green:
>>
>> 1.  I don't understand the libffi version numbers.  Can you give
>> me any explanations?  It seems to be 3.0.8 upstream but 2.1 in gcc,
>> but this doesn't seem in any way to correspond with reality.
>>
>> 2.  What's with the ChangeLog.libffi and ChangeLog.libgcj files?

>     Has there been any code exchange between the upstream libffi and
> the forked libffi that PyObjC uses? I was told the following by Bill Bumgarner
> at Apple a couple years back....

I certainly haven't done any.

Of course, any improvements from PyObjC would be considered on their merits,
just like any other submissions.

Andrew.