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 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  <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.
> 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
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]