This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [COMMITTED] Merge libffi with upstream
- From: Richard Henderson <rth at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, iant at golang dot org, Jeff Law <law at redhat dot com>
- Date: Thu, 15 Jan 2015 09:19:34 -0800
- Subject: Re: [COMMITTED] Merge libffi with upstream
- Authentication-results: sourceware.org; auth=none
- References: <54B3F790 dot 9050507 at redhat dot com> <yddsifcq9o8 dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <CAMe9rOoLn6hT05J3dDUgy+GopYVM+yiEPDKr_2nnZfeWrjcdwA at mail dot gmail dot com>
On 01/15/2015 08:54 AM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> Richard Henderson <rth@redhat.com> writes:
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers. Perhaps less relevant is new support for
>>> arc, microblaze, moxie, nios, and or1k targets.
>>>
>>> Without additional changes for Go, this merge has little effect. Within the
>>> gcc tree libffi is primarily used by libjava.
>>>
>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>>
>>> Due to upstream breakage, and difficulty debugging on Darwin,
>>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>>> 100% unchanged. Since libgo doesn't support darwin, this should cause no
>>> immediate problems.
>>
>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>
>> * on Solaris/SPARC, /bin/as requires
>>
>> .type fn,#function
>>
>> instead of @function. I've simply commented the affected lines in
>> src/sparc/v[89].S to make progress.
>>
>> * /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
>> instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>> unix64}.S.
>>
>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>> uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>
>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>> the moment.
>>
>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>> generated .eh_frame sections match, otherwise libffi.so fails to link:
>>
>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and cannot be merged into a single output section
>>
>> * Yet unfixed for Solaris/SPARC /bin/as:
>>
>> as: "v8.s", line 128: error: invalid digit in radix 10
>>
>> as seems to only understand single-digit labels
>>
>> as: "v8.s", line 140: error: statement syntax
>> as: "v8.s", line 157: error: unknown opcode ".rept"
>> as: "v8.s", line 157: error: statement syntax
>> as: "v8.s", line 163: error: unknown opcode ".endr"
>> as: "v8.s", line 163: error: statement syntax
>>
>> and knows nothing about .rept/.endr
>>
>> Here are the hacks I've used to make some progress:
>>
>
> I think we should
>
> 1. Revert the libffi merge patch.
> 2. Create a GCC integration branch from the merge commit
> in libffi git repo
How's that going to help? The build infrastructure is totally different.
That and the fact that extremely few people test upstream libffi.
> 4. Copy the the GCC integration branch to gcc/libffi, NOT the
> unmodified libffi commit.
I beg your pardon?
r~