Re: Massive breakage with your libgcc patches
I've now tried to build c6x-uclinux, not only c6x-elf, and found another
problem: crtbegin.o wasn't built. I committed the following patch;
please doublecheck there wasn't a reason for how it was being done
previously.
Bernd
Index: libgcc/config.host
===
--- libgcc/config.host (revision 181803)
+++ libgcc/config.host (working copy)
@@ -1068,9 +1068,11 @@ spu-*-elf*)
libgcc_cache64k.a libgcc_cache128k.a
;;
tic6x-*-uclinux)
- tmake_file=${tmake_file} t-softfp-sfdf t-softfp-excl t-softfp
c6x/t-elf c6x/t-uclinux t-crtstuff-pic t-libgcc-pic t-slibgcc t-slibgcc-gld
t-slibgcc-elf-ver t-gnu-prefix
+ tmake_file=${tmake_file} t-softfp-sfdf t-softfp-excl t-softfp \
+ c6x/t-elf c6x/t-uclinux t-crtstuff-pic t-libgcc-pic \
+ t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-gnu-prefix
tm_file=$tm_file c6x/c6x-abi.h
- extra_parts=crtbeginS.o crtendS.o crti.o crtn.o
+ extra_parts=$extra_parts crtbeginS.o crtendS.o crti.o crtn.o
unwind_header=config/c6x/unwind-c6x.h
;;
tic6x-*-elf)
Index: libgcc/ChangeLog
===
--- libgcc/ChangeLog(revision 181803)
+++ libgcc/ChangeLog(working copy)
@@ -1,3 +1,8 @@
+2011-11-29 Bernd Schmidt ber...@codesourcery.com
+
+ * config.host (tic6x-*-uclinux): Append to extra_parts. Fix
+ formatting.
+
2011-11-28 Rainer Orth r...@cebitec.uni-bielefeld.de
PR other/51022
Re: Massive breakage with your libgcc patches
On 11/29/2011 04:57 PM, Bernd Schmidt wrote: I've now tried to build c6x-uclinux, not only c6x-elf, and found another problem: crtbegin.o wasn't built. I committed the following patch; please doublecheck there wasn't a reason for how it was being done previously. It's ok, indeed we should look at other places where extra_parts is being overwritten erroneously. Paolo
Re: Massive breakage with your libgcc patches
Paolo Bonzini bonz...@gnu.org writes:
On 11/07/2011 07:15 PM, Rainer Orth wrote:
Bernd Schmidtber...@codesourcery.com writes:
On 11/03/11 20:20, Rainer Orth wrote:
* config/c6x/t-elf (LIB2ADDEH): Set.
* config/c6x/t-c6x-elf: Remove.
It builds now, but parts of libgcc are missing. There's no sign of
muldf3, for examples.
I found the problem: before, LIB2ADD was passed in from gcc/config via
libgcc.mvars, and added to in t-softfp. Now the order of the t-*
fragments has been kept the same, with the assignment to LIB2ADD in
c6x/t-elf overriding what has been constructed by t-softfp before.
The following patch did the trick for me, could you give it a try?
Looks ok, but these look like they could also be broken.
Sorry it took me so long, but this weekend I finally had a close look
at both the explicit settings of LIB2ADD and LIB2FUNCS_EXCLUDE. The
latter are unproblematic since the files affected are disjunct. For
LIB2ADD, here are the problematic cases. All others explicitly setting
LIB2ADD have no issues since there are no t-* fragments setting LIB2ADD
before.
i386/t-darwin64:LIB2ADD = $(srcdir)/config/darwin-64.c
The file is currently unused, was lost in the migration for
x86_64-*-darwin*. The same settings are already in i386/t-darwin, so
the file is superfluous and can be removed.
iq2000/t-iq2000:LIB2ADD = $(srcdir)/udivmod.c \
This file is unused, now restored, otherwise no problem.
pa/t-pa64:LIB2ADD = $(srcdir)/config/pa/quadlib.c
This overrides pa/t-hpux, originally we had pa/t-pa64 pa/t-pa-hpux
without overrides, but the result is ok.
rs6000/t-darwin64:LIB2ADD = $(srcdir)/config/rs6000/darwin-tramp.S \
Overrides rs6000/t-darwin, as it did before the move.
rs6000/t-lynx:LIB2ADD = $(srcdir)/config/rs6000/tramp.S
This file is currently unused, but necessary. t-lynx is also missing,
but no settings left.
rs6000/t-netbsd:LIB2ADD = $(srcdir)/config/rs6000/tramp.S
unused, necessary
sh/t-netbsd:LIB2ADD =
The override poses no problem, but is unnecessary since nothing sets
LIB2ADD before.
t-vxworks:LIB2ADD = $(srcdir)/config/vxlib.c $(srcdir)/config/vxlib-tls.c
Ok, but missing from powerpc-wrs-vxworks which didn't add to tmake_file.
The following patch implements those observations.
Ok for mainline?
Rainer
2011-11-20 Rainer Orth r...@cebitec.uni-bielefeld.de
libgcc:
* config.host (iq2000*-*-elf*): Add iq2000/t-iq2000 to tmake_file.
(powerpc-*-netbsd*): Add rs6000/t-netbsd to tmake_file.
(powerpc-wrs-vxworks, powerpc-wrs-vxworksae): Add to tmake_file.
(powerpc-*-lynxos*): Add rs6000/t-lynx to tmake_file.
* config/i386/t-darwin64: Remove.
* config/sh/t-netbsd (LIB2ADD): Remove.
# HG changeset patch
# Parent 5acb7cf614f2b6be2dd842aa54595488a6283198
Fix LIB2ADD overrides in libgcc
diff --git a/libgcc/config.host b/libgcc/config.host
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -672,7 +672,7 @@ ia64-hp-*vms*)
md_unwind_header=ia64/vms-unwind.h
;;
iq2000*-*-elf*)
- tmake_file=t-fdpbit
+ tmake_file=iq2000/t-iq2000 t-fdpbit
# Don't use default.
extra_parts=
;;
@@ -856,7 +856,7 @@ powerpc-*-freebsd*)
extra_parts=$extra_parts crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o
;;
powerpc-*-netbsd*)
- tmake_file=$tmake_file rs6000/t-crtstuff
+ tmake_file=$tmake_file rs6000/t-netbsd rs6000/t-crtstuff
;;
powerpc-*-eabispe*)
tmake_file=${tmake_file} rs6000/t-ppccomm rs6000/t-crtstuff t-crtstuff-pic
@@ -896,10 +896,10 @@ powerpc-*-linux* | powerpc64-*-linux*)
md_unwind_header=rs6000/linux-unwind.h
;;
powerpc-wrs-vxworks|powerpc-wrs-vxworksae)
- tmake_file=rs6000/t-ppccomm-ldbl t-fdpbit
+ tmake_file=$tmake_file rs6000/t-ppccomm-ldbl t-fdpbit
;;
powerpc-*-lynxos*)
- tmake_file=$tmake_file t-fdpbit
+ tmake_file=$tmake_file rs6000/t-lynx t-fdpbit
;;
powerpcle-*-elf*)
tmake_file=${tmake_file} rs6000/t-ppccomm rs6000/t-ppccomm-ldbl rs6000/t-crtstuff t-crtstuff-pic t-fdpbit
diff --git a/libgcc/config/i386/t-darwin64 b/libgcc/config/i386/t-darwin64
deleted file mode 100644
--- a/libgcc/config/i386/t-darwin64
+++ /dev/null
@@ -1,2 +0,0 @@
-LIB2_SIDITI_CONV_FUNCS = yes
-LIB2ADD = $(srcdir)/config/darwin-64.c
diff --git a/libgcc/config/sh/t-netbsd b/libgcc/config/sh/t-netbsd
--- a/libgcc/config/sh/t-netbsd
+++ b/libgcc/config/sh/t-netbsd
@@ -1,5 +1,3 @@
LIB1ASMFUNCS_CACHE = _ic_invalidate
-LIB2ADD =
-
HOST_LIBGCC2_CFLAGS += -mieee
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
On 11/21/2011 04:43 PM, Rainer Orth wrote: Paolo Bonzinibonz...@gnu.org writes: On 11/07/2011 07:15 PM, Rainer Orth wrote: Bernd Schmidtber...@codesourcery.com writes: On 11/03/11 20:20, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADDEH): Set. * config/c6x/t-c6x-elf: Remove. It builds now, but parts of libgcc are missing. There's no sign of muldf3, for examples. I found the problem: before, LIB2ADD was passed in from gcc/config via libgcc.mvars, and added to in t-softfp. Now the order of the t-* fragments has been kept the same, with the assignment to LIB2ADD in c6x/t-elf overriding what has been constructed by t-softfp before. The following patch did the trick for me, could you give it a try? Looks ok, but these look like they could also be broken. Sorry it took me so long, but this weekend I finally had a close look at both the explicit settings of LIB2ADD and LIB2FUNCS_EXCLUDE. The latter are unproblematic since the files affected are disjunct. For LIB2ADD, here are the problematic cases. All others explicitly setting LIB2ADD have no issues since there are no t-* fragments setting LIB2ADD before. i386/t-darwin64:LIB2ADD = $(srcdir)/config/darwin-64.c The file is currently unused, was lost in the migration for x86_64-*-darwin*. The same settings are already in i386/t-darwin, so the file is superfluous and can be removed. iq2000/t-iq2000:LIB2ADD = $(srcdir)/udivmod.c \ This file is unused, now restored, otherwise no problem. pa/t-pa64:LIB2ADD = $(srcdir)/config/pa/quadlib.c This overrides pa/t-hpux, originally we had pa/t-pa64 pa/t-pa-hpux without overrides, but the result is ok. rs6000/t-darwin64:LIB2ADD = $(srcdir)/config/rs6000/darwin-tramp.S \ Overrides rs6000/t-darwin, as it did before the move. rs6000/t-lynx:LIB2ADD = $(srcdir)/config/rs6000/tramp.S This file is currently unused, but necessary. t-lynx is also missing, but no settings left. rs6000/t-netbsd:LIB2ADD = $(srcdir)/config/rs6000/tramp.S unused, necessary sh/t-netbsd:LIB2ADD = The override poses no problem, but is unnecessary since nothing sets LIB2ADD before. t-vxworks:LIB2ADD = $(srcdir)/config/vxlib.c $(srcdir)/config/vxlib-tls.c Ok, but missing from powerpc-wrs-vxworks which didn't add to tmake_file. The following patch implements those observations. Ok for mainline? Rainer 2011-11-20 Rainer Orthr...@cebitec.uni-bielefeld.de libgcc: * config.host (iq2000*-*-elf*): Add iq2000/t-iq2000 to tmake_file. (powerpc-*-netbsd*): Add rs6000/t-netbsd to tmake_file. (powerpc-wrs-vxworks, powerpc-wrs-vxworksae): Add to tmake_file. (powerpc-*-lynxos*): Add rs6000/t-lynx to tmake_file. * config/i386/t-darwin64: Remove. * config/sh/t-netbsd (LIB2ADD): Remove. Ok. Paolo
Re: Massive breakage with your libgcc patches
On 11/07/2011 07:15 PM, Rainer Orth wrote: Bernd Schmidtber...@codesourcery.com writes: On 11/03/11 20:20, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADDEH): Set. * config/c6x/t-c6x-elf: Remove. It builds now, but parts of libgcc are missing. There's no sign of muldf3, for examples. I found the problem: before, LIB2ADD was passed in from gcc/config via libgcc.mvars, and added to in t-softfp. Now the order of the t-* fragments has been kept the same, with the assignment to LIB2ADD in c6x/t-elf overriding what has been constructed by t-softfp before. The following patch did the trick for me, could you give it a try? Looks ok, but these look like they could also be broken. ./config/i386/t-darwin64:LIB2ADD = $(srcdir)/config/darwin-64.c ./config/i386/t-darwin:LIB2ADD = $(srcdir)/config/darwin-64.c ./config/i386/t-gthr-win32:LIB2ADD = $(srcdir)/config/i386/gthr-win32.c ./config/spu/t-elf:LIB2ADD = _floatdisf _floatundisf _floattisf _floatunstisf ./config/rx/t-rx:LIB2ADD = $(srcdir)/config/rx/rx-abi-functions.c ./config/mep/t-mep:LIB2ADD = \ ./config/m68k/t-floatlib:LIB2ADD = $(srcdir)/config/m68k/fpgnulib.c xfgnulib.c ./config/s390/32/t-floattodi:LIB2ADD = $(addprefix $(srcdir)/config/s390/32/, $(floattodi-src)) ./config/h8300/t-h8300:LIB2ADD = \ ./config/cris/t-cris:LIB2ADD = _udivsi3.c _divsi3.c _umodsi3.c _modsi3.c ./config/ia64/t-hpux:LIB2ADD = $(srcdir)/config/ia64/quadlib.c $(srcdir)/floatunsitf.c ./config/picochip/t-picochip:LIB2ADD = \ ./config/sh/t-linux:LIB2ADD = $(srcdir)/config/sh/linux-atomic.S ./config/sh/t-netbsd:LIB2ADD = ./config/c6x/t-elf:LIB2ADD = $(srcdir)/config/c6x/gef.c \ ./config/rs6000/t-darwin64:LIB2ADD = $(srcdir)/config/rs6000/darwin-tramp.S \ ./config/rs6000/t-darwin:LIB2ADD = $(srcdir)/config/rs6000/darwin-tramp.S \ ./config/rs6000/t-lynx:LIB2ADD = $(srcdir)/config/rs6000/tramp.S ./config/rs6000/t-netbsd:LIB2ADD = $(srcdir)/config/rs6000/tramp.S ./config/pa/t-hpux:LIB2ADD = $(srcdir)/config/pa/lib2funcs.S $(srcdir)/config/pa/quadlib.c ./config/pa/t-pa64:LIB2ADD = $(srcdir)/config/pa/quadlib.c ./config/pa/t-linux:LIB2ADD = $(srcdir)/config/pa/fptr.c ./config/iq2000/t-iq2000:LIB2ADD = $(srcdir)/udivmod.c \ Paolo
Re: Massive breakage with your libgcc patches
On 11/07/11 19:15, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADD): Add instead of assigning. It does seem happier that way, please install. Please also check the list of files Paolo generated. Bernd
Re: Massive breakage with your libgcc patches
Bernd Schmidt ber...@codesourcery.com writes: On 11/07/11 19:15, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADD): Add instead of assigning. It does seem happier that way, please install. Please also check the list of files Paolo generated. Done. Checking this in other cases has been the plan all along. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
On 11/03/11 20:20, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADDEH): Set. * config/c6x/t-c6x-elf: Remove. It builds now, but parts of libgcc are missing. There's no sign of muldf3, for examples. Bernd
Re: Massive breakage with your libgcc patches
Bernd Schmidt ber...@codesourcery.com writes: On 11/03/11 20:20, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADDEH): Set. * config/c6x/t-c6x-elf: Remove. It builds now, but parts of libgcc are missing. There's no sign of muldf3, for examples. I found the problem: before, LIB2ADD was passed in from gcc/config via libgcc.mvars, and added to in t-softfp. Now the order of the t-* fragments has been kept the same, with the assignment to LIB2ADD in c6x/t-elf overriding what has been constructed by t-softfp before. The following patch did the trick for me, could you give it a try? Thanks. Rainer 2011-11-07 Rainer Orth r...@cebitec.uni-bielefeld.de * config/c6x/t-elf (LIB2ADD): Add instead of assigning. diff --git a/libgcc/config/c6x/t-elf b/libgcc/config/c6x/t-elf --- a/libgcc/config/c6x/t-elf +++ b/libgcc/config/c6x/t-elf @@ -8,7 +8,7 @@ LIB1ASMFUNCS += _push_rts _pop_rts _call LIB2FUNCS_EXCLUDE = _cmpdi2 _ucmpdi2 _gcc_bcmp _eprintf _clzsi _clzdi -LIB2ADD = $(srcdir)/config/c6x/gef.c \ +LIB2ADD += $(srcdir)/config/c6x/gef.c \ $(srcdir)/config/c6x/gtf.c \ $(srcdir)/config/c6x/lef.c \ $(srcdir)/config/c6x/ltf.c \ -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
On 11/03/11 20:20, Rainer Orth wrote: Here's the patch I've come up with. Should I commit it now or would you like to do a full testsuite run first? Please commit, thanks. Bernd
Re: Massive breakage with your libgcc patches
Hans-Peter Nilsson hans-peter.nils...@axis.com writes: For big changes such as this, please test on a cross configuration as well. A random cross wouldn't help, and I'd claim it's impractical to set up full cross environments for all affected targets. That's why I repeatedly send calls for testers, with exactly no reaction at all ;-( For cris-elf, a patch in the range 180770:180778 supposedly yours, cause massive testsuite failures on the form of not finding functions in libgcc at link-time. From gcc.log: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1-lib.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O0-isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/complex-1.x0 (timeout = 300) /tmp/ccAbw5Fs.o: In function `main_test': complex-1.c:(.text+0x9e): undefined reference to `__nesf2' complex-1.c:(.text+0xb8): undefined reference to `__nesf2' complex-1.c:(.text+0xfa): undefined reference to `__nesf2' complex-1.c:(.text+0x114): undefined reference to `__nesf2' complex-1.c:(.text+0x142): undefined reference to `__nesf2' /tmp/ccAbw5Fs.o:complex-1.c:(.text+0x162): more undefined references to `__nesf2' follow Do you have an old build lying around to check where that symbol came from before and why that object isn't built any longer/not included libgcc? Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
Bernd Schmidt ber...@codesourcery.com writes: c6x-elf cross builds are also broken with failures in libgcc/. Rainer, can you investigate? Can you provide details? It probably would take quite some time for me to set up a full cross environment, and perhaps I can spot what's amiss without doing so. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
On 11/03/11 14:12, Rainer Orth wrote: Bernd Schmidt ber...@codesourcery.com writes: c6x-elf cross builds are also broken with failures in libgcc/. Rainer, can you investigate? Can you provide details? It probably would take quite some time for me to set up a full cross environment, and perhaps I can spot what's amiss without doing so. A cross environment for -elf targets typicaly just requires building up binutils/newlib, and that should be rather quick to set up. A set of patches of this magnitude really ought to have had more testing (the CFT was useless as the patches bitrotted almost immediately and didn't apply anymore), and not everything should have been applied at once. Anyhow, the errors: In file included from ../../../../baseline-trunk/libgcc/unwind-dw2.c:39:0: ../../../../baseline-trunk/libgcc/unwind-dw2.h:77:3: error: unknown type name ���_Unwind_Personality_Fn��� ../../../../baseline-trunk/libgcc/unwind-dw2.c:196:1: error: redefinition of ���_Unwind_GetGR��� In file included from ./unwind.h:31:0, from ../../../../baseline-trunk/libgcc/unwind-dw2.c:32: /local/src/egcs/bc6x-baseline/./gcc/include/unwind-arm-common.h:221:3: note: previous definition of ���_Unwind_GetGR��� was here ../../../../baseline-trunk/libgcc/unwind-dw2.c:241:1: error: redefinition of ���_Unwind_SetGR��� In file included from ./unwind.h:31:0, from ../../../../baseline-trunk/libgcc/unwind-dw2.c:32: /local/src/egcs/bc6x-baseline/./gcc/include/unwind-arm-common.h:232:3: note: previous definition of ���_Unwind_SetGR��� was here ../../../../baseline-trunk/libgcc/unwind-dw2.c:316:1: error: expected declaration specifiers or ���...��� before numeric constant ../../../../baseline-trunk/libgcc/unwind-dw2.c:325:1: error: expected identifier or ���(��� before ���int��� ../../../../baseline-trunk/libgcc/unwind-dw2.c:334:1: error: expected declaration specifiers or ���...��� before numeric constant ../../../../baseline-trunk/libgcc/unwind-dw2.c:352:1: warning: no previous prototype for ���_Unwind_FindEnclosingFunction��� [-Wmissing-prototypes] ../../../../baseline-trunk/libgcc/unwind-dw2.c: In function ���extract_cie_info���: ../../../../baseline-trunk/libgcc/unwind-dw2.c:460:23: error: ���_Unwind_Personality_Fn��� undeclared (first use in this function) ../../../../baseline-trunk/libgcc/unwind-dw2.c:460:23: note: each undeclared identifier is reported only once for each function it appears in ../../../../baseline-trunk/libgcc/unwind-dw2.c:460:47: error: expected ���;��� before ���personality��� ../../../../baseline-trunk/libgcc/unwind-dw2.c: In function ���uw_frame_state_for���: ../../../../baseline-trunk/libgcc/unwind-dw2.c:1199:12: error: ���_URC_FATAL_PHASE1_ERROR��� undeclared (first use in this function) In file included from ../../../../baseline-trunk/libgcc/unwind-dw2.c:1632:0: ../../../../baseline-trunk/libgcc/unwind.inc: In function ���_Unwind_RaiseException_Phase2���: ../../../../baseline-trunk/libgcc/unwind.inc:51:60: error: ���struct _Unwind_Control_Block��� has no member named ���private_2��� ../../../../baseline-trunk/libgcc/unwind.inc:57:9: error: ���_URC_FATAL_PHASE2_ERROR��� undeclared (first use in this function) ../../../../baseline-trunk/libgcc/unwind.inc:62:12: error: invalid type argument of unary ���*��� (have ���int���) ../../../../baseline-trunk/libgcc/unwind.inc: At top level: ../../../../baseline-trunk/libgcc/unwind.inc:82:1: error: expected ���=���, ���,���, ���;���, ���asm��� or ���__attribute__��� before ���_Unwind_RaiseException��� ../../../../baseline-trunk/libgcc/unwind.inc: In function ���_Unwind_ForcedUnwind_Phase2���: ../../../../baseline-trunk/libgcc/unwind.inc:145:61: error: ���struct _Unwind_Control_Block��� has no member named ���private_1��� ../../../../baseline-trunk/libgcc/unwind.inc:146:51: error: ���struct _Unwind_Control_Block��� has no member named ���private_2��� ../../../../baseline-trunk/libgcc/unwind.inc:157:9: error: ���_URC_FATAL_PHASE2_ERROR��� undeclared (first use in this function) ../../../../baseline-trunk/libgcc/unwind.inc:175:12: error: invalid type argument of unary ���*��� (have ���int���) ../../../../baseline-trunk/libgcc/unwind.inc: At top level: ../../../../baseline-trunk/libgcc/unwind.inc:195:1: error: expected ���=���, ���,���, ���;���, ���asm��� or ���__attribute__��� before ���_Unwind_ForcedUnwind��� ../../../../baseline-trunk/libgcc/unwind.inc:219:1: error: expected ���=���, ���,���, ���;���, ���asm��� or ���__attribute__��� before ���_Unwind_Resume��� ../../../../baseline-trunk/libgcc/unwind.inc:244:1: error: expected ���=���, ���,���, ���;���, ���asm��� or ���__attribute__��� before ���_Unwind_Resume_or_Rethrow��� ../../../../baseline-trunk/libgcc/unwind.inc:278:1: error: expected ���=���, ���,���, ���;���, ���asm��� or ���__attribute__��� before ���_Unwind_Backtrace��� ../../../../baseline-trunk/libgcc/unwind-dw2.c:1487:1: warning: ���uw_init_context_1��� defined but not used [-Wunused-function]
Re: Massive breakage with your libgcc patches
From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Thu, 3 Nov 2011 14:10:50 +0100 Hans-Peter Nilsson hans-peter.nils...@axis.com writes: For big changes such as this, please test on a cross configuration as well. A random cross wouldn't help, and I'd claim it's impractical to set up full cross environments for all affected targets. I beg to differ on both accounts. A single cross would have provided a smoke-test and once a *-elf is set up, you can reuse that for other *-elf (or *-eabi) targets as well. As Bernd mentioned, newlib, binutils - and sim are all that's needed; different --target=* options and different RUNTESTFLAGS=--target_board=* options. See simtest-howto.html. That's why I repeatedly send calls for testers, with exactly no reaction at all ;-( But isn't that a clue? Looking in my mail, I see a stream of patches from Aug 15, which I reviewed. I don't see anything CC:ed to me after Aug 16 until yesterday. For cris-elf, a patch in the range 180770:180778 supposedly yours, cause massive testsuite failures on the form of not finding functions in libgcc at link-time. From gcc.log: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1-lib.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O0-isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/complex-1.x0 (timeout = 300) /tmp/ccAbw5Fs.o: In function `main_test': complex-1.c:(.text+0x9e): undefined reference to `__nesf2' complex-1.c:(.text+0xb8): undefined reference to `__nesf2' complex-1.c:(.text+0xfa): undefined reference to `__nesf2' complex-1.c:(.text+0x114): undefined reference to `__nesf2' complex-1.c:(.text+0x142): undefined reference to `__nesf2' /tmp/ccAbw5Fs.o:complex-1.c:(.text+0x162): more undefined references to `__nesf2' follow Do you have an old build lying around to check where that symbol came from before libgcc.a ... and why that object isn't built any longer/not included libgcc? Ah, the bug? Nm, I'll go fix it myself. (This is the kind of back-and-forth that's just so time-consuming that I'd rather not. Film at 11.) brgds, H-P
Re: Massive breakage with your libgcc patches
From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Thu, 3 Nov 2011 14:10:50 +0100 Hans-Peter Nilsson hans-peter.nils...@axis.com writes: For cris-elf, a patch in the range 180770:180778 supposedly yours, cause massive testsuite failures on the form of not finding functions in libgcc at link-time. It seems it was just a missing t-fdpbit for cris-*-elf. I'll test the obvious fix (fingers crossed). The testing issue aside, thanks for doing this work and staying on it. brgds, H-P
Re: Massive breakage with your libgcc patches
Hans-Peter Nilsson hans-peter.nils...@axis.com writes: From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Thu, 3 Nov 2011 14:10:50 +0100 Hans-Peter Nilsson hans-peter.nils...@axis.com writes: For cris-elf, a patch in the range 180770:180778 supposedly yours, cause massive testsuite failures on the form of not finding functions in libgcc at link-time. It seems it was just a missing t-fdpbit for cris-*-elf. I'll test the obvious fix (fingers crossed). I'm glad if it's that easy (though stupid ;-) Thanks for the detective work. The testing issue aside, thanks for doing this work and staying on it. Thanks. I had been looking into crosstool-NG for easily setting up a cross environment, but several issues got in the way. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
Bernd Schmidt ber...@codesourcery.com writes: On 11/03/11 14:12, Rainer Orth wrote: Bernd Schmidt ber...@codesourcery.com writes: c6x-elf cross builds are also broken with failures in libgcc/. Rainer, can you investigate? Can you provide details? It probably would take quite some time for me to set up a full cross environment, and perhaps I can spot what's amiss without doing so. A cross environment for -elf targets typicaly just requires building up binutils/newlib, and that should be rather quick to set up. A set of Maybe in theory, but for the case at hand, a c6x-elf configuration with binutils from the top of the binutils 2.22 branch fails to configure libgcc: checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 The test fails like this: configure:4514: checking whether to use setjmp/longjmp exceptions configure:: /var/gcc/c6x-elf/obj/gcc/./gcc/xgcc -B/var/gcc/c6x-elf/obj/gcc/./gcc/ -B/usr/local/c6x-elf/bin/ -B/usr/local/c6x-elf/lib/ -isystem /usr/local/c6x-elf/include -isystem /usr/local/c6x-elf/sys-include-c --save-temps -fexceptions conftest.c 5 conftest.s: Assembler messages: conftest.s:63: Error: duplicate .personality directive conftest.s:64: Error: unexpected .handlerdata directive configure:: $? = 1 The assembler error seems bogus, the .s file has .LFE0: .global __gcc_personality_v0 .personality__gcc_personality_v0 .handlerdata .LLSDA0: .byte 0xff where the .personality directive is the first and only in the file. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
On 11/03/11 18:01, Rainer Orth wrote: Bernd Schmidt ber...@codesourcery.com writes: A cross environment for -elf targets typicaly just requires building up binutils/newlib, and that should be rather quick to set up. A set of Maybe in theory, but for the case at hand, a c6x-elf configuration with binutils from the top of the binutils 2.22 branch fails to configure libgcc: checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 That does not appear to be happening here, neither with 2.22 nor CVS head. Please verify how you configured and built binutils and gcc. Bernd
Re: Massive breakage with your libgcc patches
Bernd Schmidt ber...@codesourcery.com writes: [Trimming the Cc: list.] On 11/03/11 18:01, Rainer Orth wrote: Bernd Schmidt ber...@codesourcery.com writes: A cross environment for -elf targets typicaly just requires building up binutils/newlib, and that should be rather quick to set up. A set of Maybe in theory, but for the case at hand, a c6x-elf configuration with binutils from the top of the binutils 2.22 branch fails to configure libgcc: checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 That does not appear to be happening here, neither with 2.22 nor CVS head. Please verify how you configured and built binutils and gcc. Nothing unusual AFAICS: $ /vol/src/gnu/binutils/binutils-2.22-branch/configure --prefix=/var/gcc/c6x-elf --target c6x-elf $ PATH=/var/gcc/c6x-elf/bin:$PATH /vol/gcc/src/hg/trunk/local/configure --target c6x-elf --with-gmp=/vol/gcc --without-ppl --without-cloog --enable-languages=c --with-gnu-as --with-as=/var/gcc/c6x-elf/bin/c6x-elf-as --with-gnu-ld --with-ld=/var/gcc/c6x-elf/bin/c6x-elf-ld All on x86_64-unknown-linux-gnu. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Massive breakage with your libgcc patches
On 11/03/11 19:12, Rainer Orth wrote: Bernd Schmidt ber...@codesourcery.com writes: [Trimming the Cc: list.] On 11/03/11 18:01, Rainer Orth wrote: Bernd Schmidt ber...@codesourcery.com writes: A cross environment for -elf targets typicaly just requires building up binutils/newlib, and that should be rather quick to set up. A set of Maybe in theory, but for the case at hand, a c6x-elf configuration with binutils from the top of the binutils 2.22 branch fails to configure libgcc: checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 That does not appear to be happening here, neither with 2.22 nor CVS head. Please verify how you configured and built binutils and gcc. Nothing unusual AFAICS: $ /vol/src/gnu/binutils/binutils-2.22-branch/configure --prefix=/var/gcc/c6x-elf --target c6x-elf $ PATH=/var/gcc/c6x-elf/bin:$PATH /vol/gcc/src/hg/trunk/local/configure --target c6x-elf --with-gmp=/vol/gcc --without-ppl --without-cloog --enable-languages=c --with-gnu-as --with-as=/var/gcc/c6x-elf/bin/c6x-elf-as --with-gnu-ld --with-ld=/var/gcc/c6x-elf/bin/c6x-elf-ld All on x86_64-unknown-linux-gnu. I've tried again on x86_64, still no such failure. Are you quite sure the binutils directory is up-to-date? (Try a clean checkout with CVS). You can drop most of the gcc configure options if the tools are in your path. Bernd
Re: Massive breakage with your libgcc patches
Bernd Schmidt ber...@codesourcery.com writes: I've tried again on x86_64, still no such failure. Are you quite sure the binutils directory is up-to-date? (Try a clean checkout with CVS). It was up-to-date, but somehow mangled (haven't yet investigated how/why). Anyway, with a fresh anon-CVS checkout of the 2.22 branch, I can now build libgcc up to the failure point. You can drop most of the gcc configure options if the tools are in your path. I wasn't completely certain about it and wanted to avoid a possible source of problems. I've now managed to reproduce the problem. In a checkout of the gcc tree before my patches, unwind-dw2.o isn't built. I could trace this to LIB2ADD_EH not being overridden any longer, so the default was used. I had missed the addition of libgcc/config/c6x/t-c6x-elf since I've normalized the names of the target fragments to consistently use $cpu/t-elf, not $cpu/t-$cpu-elf. Simply merging the contents of c6x/t-c6x-elf into c6x/t-elf allowed the libgcc build to complete for me. Here's the patch I've come up with. Should I commit it now or would you like to do a full testsuite run first? Sorry again for the trouble. Rainer 2011-11-03 Rainer Orth r...@cebitec.uni-bielefeld.de * config/c6x/t-elf (LIB2ADDEH): Set. * config/c6x/t-c6x-elf: Remove. # HG changeset patch # Parent 42f16488e80434634dcd1100a993e7f81c37ada8 Restore c6x-elf bootstrap diff --git a/libgcc/config/c6x/t-c6x-elf b/libgcc/config/c6x/t-c6x-elf deleted file mode 100644 --- a/libgcc/config/c6x/t-c6x-elf +++ /dev/null @@ -1,4 +0,0 @@ -LIB2ADDEH = $(srcdir)/config/c6x/unwind-c6x.c \ - $(srcdir)/config/c6x/libunwind.S \ - $(srcdir)/config/c6x/pr-support.c $(srcdir)/unwind-c.c - diff --git a/libgcc/config/c6x/t-elf b/libgcc/config/c6x/t-elf --- a/libgcc/config/c6x/t-elf +++ b/libgcc/config/c6x/t-elf @@ -22,6 +22,10 @@ LIB2ADD = $(srcdir)/config/c6x/gef.c \ # Avoid failures when the user's GOT becomes too large. HOST_LIBGCC2_CFLAGS = -msdata=none +LIB2ADDEH = $(srcdir)/config/c6x/unwind-c6x.c \ + $(srcdir)/config/c6x/libunwind.S \ + $(srcdir)/config/c6x/pr-support.c $(srcdir)/unwind-c.c + # Assemble startup files. crti.o: $(srcdir)/config/c6x/crti.S $(crt_compile) -c $(CRTSTUFF_T_CFLAGS) $ -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Massive breakage with your libgcc patches
From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Wed, 2 Nov 2011 13:37:33 +0100 Rainer Orth r...@cebitec.uni-bielefeld.de writes: The next patch in the series moves crtstuff.c, extra_parts, EXTRA_PARTS, EXTRA_MULTILIB_PARTS and referenced files to libgcc. This will avoid errors due to inconsistencies in extra_parts between gcc and libgcc in the future. Much of this is pretty mechanical, but given that I cannot test most of the platforms, there are likely to be mistakes in the process. Given Joseph's approval, I'm about to check in the following rebased version of the patch, after regtesting on i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-unknown-linux-gnu, i386-apple-darwin9.8.0, and powerpc-apple-darwin9.8.0. For big changes such as this, please test on a cross configuration as well. For cris-elf, a patch in the range 180770:180778 supposedly yours, cause massive testsuite failures on the form of not finding functions in libgcc at link-time. From gcc.log: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/complex-1-lib.c /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O0-isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -lm -o /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/complex-1.x0(timeout = 300) /tmp/ccAbw5Fs.o: In function `main_test': complex-1.c:(.text+0x9e): undefined reference to `__nesf2' complex-1.c:(.text+0xb8): undefined reference to `__nesf2' complex-1.c:(.text+0xfa): undefined reference to `__nesf2' complex-1.c:(.text+0x114): undefined reference to `__nesf2' complex-1.c:(.text+0x142): undefined reference to `__nesf2' /tmp/ccAbw5Fs.o:complex-1.c:(.text+0x162): more undefined references to `__nesf2' follow brgds, H-P
