This is the mail archive of the
mailing list for the GCC project.
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 <firstname.lastname@example.org>
> >>> 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.
> 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 Jarno GPG: 4096R/1DDD8C9B