On Thu, Jan 15, 2015 at 9:19 AM, Richard Henderson <r...@redhat.com> wrote:
> On 01/15/2015 08:54 AM, H.J. Lu wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>> <r...@cebitec.uni-bielefeld.de> wrote:
>>> Richard Henderson <r...@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.
It is to make sure that all GCC customization changes don't
get lost when merging with upstream. I am willing to work on
this and create a GCC patch to combine steps 1-4.
>> 4. Copy the the GCC integration branch to gcc/libffi, NOT the
>> unmodified libffi commit.
>
> I beg your pardon?
>
>
> r~
>
--
H.J.
