This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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 <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.
jeff