Re: [PATCH] Sync MIPS support from libffi master repository
On 9/11/19 1:12 PM, Aurelien Jarno wrote: > On 2019-08-08 16:22, Jeff Law wrote: >> On 8/8/19 4:18 PM, Aurelien Jarno wrote: >>> >>> It is used by libgo, but it seems to be the last user. >> Ah, yes, I should have remembered libgo. And it links via >> ../../blahblah. Thanks for digging into it. >> >> So, yea, we need it. So I think the best path forward is to just resync >> everything to the upstream master. > > I have noticed that parisc and riscv support have commits that haven't > been propagated on the upstream libffi side. Things might be easier to > sync if those changes get merged on the libffi side. > FWIW, I bugged Anthony & DJ about libffi a bit during our team meetings earlier this week. Essentially my goal was to emphasize to them that getting a release out the door was desperately needed. I doubt that changes any of the calculus here. At least according out the ChangeLog we've only backported RISC-V bits from upstream. It's not as clear for the PA bits John checked in a few years ago. jeff
Re: [PATCH] Sync MIPS support from libffi master repository
On 2019-08-08 16:22, Jeff Law wrote: > On 8/8/19 4:18 PM, Aurelien Jarno wrote: > > > > It is used by libgo, but it seems to be the last user. > Ah, yes, I should have remembered libgo. And it links via > ../../blahblah. Thanks for digging into it. > > So, yea, we need it. So I think the best path forward is to just resync > everything to the upstream master. I have noticed that parisc and riscv support have commits that haven't been propagated on the upstream libffi side. Things might be easier to sync if those changes get merged on the libffi side. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Sync MIPS support from libffi master repository
On 8/8/19 4:18 PM, Aurelien Jarno wrote: > > It is used by libgo, but it seems to be the last user. Ah, yes, I should have remembered libgo. And it links via ../../blahblah. Thanks for digging into it. So, yea, we need it. So I think the best path forward is to just resync everything to the upstream master. Jeff
Re: [PATCH] Sync MIPS support from libffi master repository
On 2019-08-08 15:00, Jeff Law wrote: > On 8/8/19 2:56 PM, Aurelien Jarno wrote: > > On 2019-08-08 14:41, Jeff Law wrote: > >> On 8/5/19 2:33 PM, Aurelien Jarno wrote: > >>> This updates the libffi MIPS support up to commit 746dbe3a6a79, with the > >>> exception of commit bd72848c7af9 which prefixes the ALIGN macro with > >>> FFI_ for all ports. > >>> > >>> These patches, with the exception of the softfloat one, have been used > >>> on the Debian GCC packages for quite some time. > >>> > >>> libffi/Changelog: > >>> > >>> 2019-08-05 Aurelien Jarno > >>> > >>> Import from upstream > >>> * src/mips/ffi.c (ffi_call_O32, ffi_call_N32, > >>> ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust > >>> interface. > >>> (ffi_call_int): Renamed from ffi_call. > >>> (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions. > >>> (ffi_prep_closure_loc): Define jr instruction for R6. > >>> * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define. > >>> (FFI_TRAMPOLINE_SIZE): Define to 56 for N64. > >>> Test for __linux__ instead of linux. > >>> * src/mips/n32.S (ffi_go_closure_N32): New function. > >>> (ffi_call_N32): Adjust code for softfloat. > >>> (.set mips4): Guard with !defined(__mips_isa_rev) || > >>> (__mips_isa_rev<6). > >>> * src/mips/o32.S (ffi_go_closure_O32): New function. > >>> (ffi_call_O32): Adjust code for softfloat. > >> What's the motivation here? > > > > The original motivation is that it improves go support on MIPS in > > general and fixes it on MIPS R6. > > > > The more recent motivation is that Debian has been patching GCC with > > those changes for quite some time, however we are now requested that > > those patches are merged upstream. > Understood. > > > > >> Would we just be better off moving all of libffi forward rather than > >> just MIPS bits? > > > > Looking at the history, each port has be doing its own sync from libffi. > > Now I agree with you that if possible, moving all of libffi forward > > looks like a good idea. > If we still need libffi, this would be my preference... But... > > > > >> Do we even still need a bundled libffi in GCC anymore? > > > > The issue might be that the last libffi release has been done 5 years > > ago, and most of the recent commits done in the libffi/ directory are > > not present in a released version of libffi. > > > > Otherwise I do not have idea if it is feasible to use the shared libffi > > library. > My point is I'm not even sure we're using libffi within gcc anymore. I > know we used it for Java bits, but that was killed some time ago. Some > quick grepping for lffi, ffi.h and ffitarget.h aren't turning up > anything outside the libffi directory itself. So I really question if > we still need it at all within gcc. It is used by libgo, but it seems to be the last user. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Sync MIPS support from libffi master repository
On 8/8/19 2:56 PM, Aurelien Jarno wrote: > On 2019-08-08 14:41, Jeff Law wrote: >> On 8/5/19 2:33 PM, Aurelien Jarno wrote: >>> This updates the libffi MIPS support up to commit 746dbe3a6a79, with the >>> exception of commit bd72848c7af9 which prefixes the ALIGN macro with >>> FFI_ for all ports. >>> >>> These patches, with the exception of the softfloat one, have been used >>> on the Debian GCC packages for quite some time. >>> >>> libffi/Changelog: >>> >>> 2019-08-05 Aurelien Jarno >>> >>> Import from upstream >>> * src/mips/ffi.c (ffi_call_O32, ffi_call_N32, >>> ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust >>> interface. >>> (ffi_call_int): Renamed from ffi_call. >>> (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions. >>> (ffi_prep_closure_loc): Define jr instruction for R6. >>> * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define. >>> (FFI_TRAMPOLINE_SIZE): Define to 56 for N64. >>> Test for __linux__ instead of linux. >>> * src/mips/n32.S (ffi_go_closure_N32): New function. >>> (ffi_call_N32): Adjust code for softfloat. >>> (.set mips4): Guard with !defined(__mips_isa_rev) || >>> (__mips_isa_rev<6). >>> * src/mips/o32.S (ffi_go_closure_O32): New function. >>> (ffi_call_O32): Adjust code for softfloat. >> What's the motivation here? > > The original motivation is that it improves go support on MIPS in > general and fixes it on MIPS R6. > > The more recent motivation is that Debian has been patching GCC with > those changes for quite some time, however we are now requested that > those patches are merged upstream. Understood. > >> Would we just be better off moving all of libffi forward rather than >> just MIPS bits? > > Looking at the history, each port has be doing its own sync from libffi. > Now I agree with you that if possible, moving all of libffi forward > looks like a good idea. If we still need libffi, this would be my preference... But... > >> Do we even still need a bundled libffi in GCC anymore? > > The issue might be that the last libffi release has been done 5 years > ago, and most of the recent commits done in the libffi/ directory are > not present in a released version of libffi. > > Otherwise I do not have idea if it is feasible to use the shared libffi > library. My point is I'm not even sure we're using libffi within gcc anymore. I know we used it for Java bits, but that was killed some time ago. Some quick grepping for lffi, ffi.h and ffitarget.h aren't turning up anything outside the libffi directory itself. So I really question if we still need it at all within gcc. jeff
Re: [PATCH] Sync MIPS support from libffi master repository
On 2019-08-08 14:41, Jeff Law wrote: > On 8/5/19 2:33 PM, Aurelien Jarno wrote: > > This updates the libffi MIPS support up to commit 746dbe3a6a79, with the > > exception of commit bd72848c7af9 which prefixes the ALIGN macro with > > FFI_ for all ports. > > > > These patches, with the exception of the softfloat one, have been used > > on the Debian GCC packages for quite some time. > > > > libffi/Changelog: > > > > 2019-08-05 Aurelien Jarno > > > > Import from upstream > > * src/mips/ffi.c (ffi_call_O32, ffi_call_N32, > > ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust > > interface. > > (ffi_call_int): Renamed from ffi_call. > > (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions. > > (ffi_prep_closure_loc): Define jr instruction for R6. > > * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define. > > (FFI_TRAMPOLINE_SIZE): Define to 56 for N64. > > Test for __linux__ instead of linux. > > * src/mips/n32.S (ffi_go_closure_N32): New function. > > (ffi_call_N32): Adjust code for softfloat. > > (.set mips4): Guard with !defined(__mips_isa_rev) || > > (__mips_isa_rev<6). > > * src/mips/o32.S (ffi_go_closure_O32): New function. > > (ffi_call_O32): Adjust code for softfloat. > What's the motivation here? The original motivation is that it improves go support on MIPS in general and fixes it on MIPS R6. The more recent motivation is that Debian has been patching GCC with those changes for quite some time, however we are now requested that those patches are merged upstream. > Would we just be better off moving all of libffi forward rather than > just MIPS bits? Looking at the history, each port has be doing its own sync from libffi. Now I agree with you that if possible, moving all of libffi forward looks like a good idea. > Do we even still need a bundled libffi in GCC anymore? The issue might be that the last libffi release has been done 5 years ago, and most of the recent commits done in the libffi/ directory are not present in a released version of libffi. Otherwise I do not have idea if it is feasible to use the shared libffi library. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Sync MIPS support from libffi master repository
On 8/5/19 2:33 PM, Aurelien Jarno wrote: > This updates the libffi MIPS support up to commit 746dbe3a6a79, with the > exception of commit bd72848c7af9 which prefixes the ALIGN macro with > FFI_ for all ports. > > These patches, with the exception of the softfloat one, have been used > on the Debian GCC packages for quite some time. > > libffi/Changelog: > > 2019-08-05 Aurelien Jarno > > Import from upstream > * src/mips/ffi.c (ffi_call_O32, ffi_call_N32, > ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust > interface. > (ffi_call_int): Renamed from ffi_call. > (ffi_call, ffi_call_go, ffi_prep_go_closure): New functions. > (ffi_prep_closure_loc): Define jr instruction for R6. > * src/mips/ffitarget.h (FFI_GO_CLOSURES): Define. > (FFI_TRAMPOLINE_SIZE): Define to 56 for N64. > Test for __linux__ instead of linux. > * src/mips/n32.S (ffi_go_closure_N32): New function. > (ffi_call_N32): Adjust code for softfloat. > (.set mips4): Guard with !defined(__mips_isa_rev) || > (__mips_isa_rev<6). > * src/mips/o32.S (ffi_go_closure_O32): New function. > (ffi_call_O32): Adjust code for softfloat. What's the motivation here? Would we just be better off moving all of libffi forward rather than just MIPS bits? Do we even still need a bundled libffi in GCC anymore? Jeff
[PATCH] Sync MIPS support from libffi master repository
This updates the libffi MIPS support up to commit 746dbe3a6a79, with the
exception of commit bd72848c7af9 which prefixes the ALIGN macro with
FFI_ for all ports.
These patches, with the exception of the softfloat one, have been used
on the Debian GCC packages for quite some time.
libffi/Changelog:
2019-08-05 Aurelien Jarno
Import from upstream
* src/mips/ffi.c (ffi_call_O32, ffi_call_N32,
ffi_closure_mips_inner_O32, ffi_closure_mips_inner_N32): Adjust
interface.
(ffi_call_int): Renamed from ffi_call.
(ffi_call, ffi_call_go, ffi_prep_go_closure): New functions.
(ffi_prep_closure_loc): Define jr instruction for R6.
* src/mips/ffitarget.h (FFI_GO_CLOSURES): Define.
(FFI_TRAMPOLINE_SIZE): Define to 56 for N64.
Test for __linux__ instead of linux.
* src/mips/n32.S (ffi_go_closure_N32): New function.
(ffi_call_N32): Adjust code for softfloat.
(.set mips4): Guard with !defined(__mips_isa_rev) ||
(__mips_isa_rev<6).
* src/mips/o32.S (ffi_go_closure_O32): New function.
(ffi_call_O32): Adjust code for softfloat.
diff --git a/libffi/src/mips/ffi.c b/libffi/src/mips/ffi.c
index 5d0dd70cb32..70a2081b498 100644
--- a/libffi/src/mips/ffi.c
+++ b/libffi/src/mips/ffi.c
@@ -581,14 +581,15 @@ ffi_status ffi_prep_cif_machdep(ffi_cif *cif)
/* Low level routine for calling O32 functions */
extern int ffi_call_O32(void (*)(char *, extended_cif *, int, int),
extended_cif *, unsigned,
- unsigned, unsigned *, void (*)(void));
+ unsigned, unsigned *, void (*)(void), void *closure);
/* Low level routine for calling N32 functions */
extern int ffi_call_N32(void (*)(char *, extended_cif *, int, int),
extended_cif *, unsigned,
- unsigned, void *, void (*)(void));
+ unsigned, void *, void (*)(void), void *closure);
-void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
+void ffi_call_int(ffi_cif *cif, void (*fn)(void), void *rvalue,
+ void **avalue, void *closure)
{
extended_cif ecif;
@@ -610,7 +611,7 @@ void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue,
void **avalue)
case FFI_O32:
case FFI_O32_SOFT_FLOAT:
ffi_call_O32(ffi_prep_args, &ecif, cif->bytes,
- cif->flags, ecif.rvalue, fn);
+ cif->flags, ecif.rvalue, fn, closure);
break;
#endif
@@ -642,7 +643,7 @@ void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue,
void **avalue)
#endif
}
ffi_call_N32(ffi_prep_args, &ecif, cif->bytes,
- cif->flags, rvalue_copy, fn);
+ cif->flags, rvalue_copy, fn, closure);
if (copy_rvalue)
memcpy(ecif.rvalue, rvalue_copy + copy_offset, cif->rtype->size);
}
@@ -655,11 +656,27 @@ void ffi_call(ffi_cif *cif, void (*fn)(void), void
*rvalue, void **avalue)
}
}
+void
+ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
+{
+ ffi_call_int (cif, fn, rvalue, avalue, NULL);
+}
+
+void
+ffi_call_go (ffi_cif *cif, void (*fn)(void), void *rvalue,
+void **avalue, void *closure)
+{
+ ffi_call_int (cif, fn, rvalue, avalue, closure);
+}
+
+
#if FFI_CLOSURES
#if defined(FFI_MIPS_O32)
extern void ffi_closure_O32(void);
+extern void ffi_go_closure_O32(void);
#else
extern void ffi_closure_N32(void);
+extern void ffi_go_closure_N32(void);
#endif /* FFI_MIPS_O32 */
ffi_status
@@ -698,7 +715,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
/* lui $12,high(codeloc) */
tramp[2] = 0x3c0c | ((unsigned)codeloc >> 16);
/* jr $25 */
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
tramp[3] = 0x0328;
+#else
+ tramp[3] = 0x0329;
+#endif
/* ori $12,low(codeloc) */
tramp[4] = 0x358c | ((unsigned)codeloc & 0x);
#else
@@ -726,7 +747,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
/* ori $25,low(fn) */
tramp[10] = 0x3739 | ((unsigned long)fn & 0x);
/* jr $25 */
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
tramp[11] = 0x0328;
+#else
+ tramp[11] = 0x0329;
+#endif
/* ori $12,low(codeloc) */
tramp[12] = 0x358c | ((unsigned long)codeloc & 0x);
@@ -762,17 +787,17 @@ ffi_prep_closure_loc (ffi_closure *closure,
* Based on the similar routine for sparc.
*/
int
-ffi_closure_mips_inner_O32 (ffi_closure *closure,
+ffi_closure_mips_inner_O32 (ffi_cif *cif,
+void (*fun)(ffi_cif*, void*, void**, void*),
+ void *user_data,
void *rvalue, ffi_arg *ar,
double *fpr)
{
- ffi_cif *cif;
void **avaluep;
ffi_arg *avalue;
ffi_type **arg_types;
int i, avn, argn, seen_int;
- cif = closure->cif;
avalue = alloca (cif->nargs * sizeof (ffi_
