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. > 4. Copy the the GCC integration branch to gcc/libffi, NOT the > unmodified libffi commit. I beg your pardon? r~