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 <aurel...@aurel32.net> > >>> > >>> 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
