This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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  <aurelien@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.

> 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
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]