building the gcc-4.2.0 RC2 with binutils_20070426 on Debian unstable, some hundred testcases fail like: PASS: g++.dg/other/classkey1.C (test for excess errors) Executing on host: /scratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/build/gcc/testsuite/g++/../../g++ -B/s cratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/build/gcc/testsuite/g++/../../ /scratch/packages/gcc/4.2/gc c-4.2-4.2-20070502/src/gcc/testsuite/g++.dg/other/complex1.C -nostdinc++ -I/scratch/packages/gcc/4.2/gc c-4.2-4.2-20070502/build/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/scratch/packages/gcc/4.2/ gcc-4.2-4.2-20070502/build/hppa-linux-gnu/libstdc++-v3/include -I/scratch/packages/gcc/4.2/gcc-4.2-4.2-2 0070502/src/libstdc++-v3/libsupc++ -I/scratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/src/libstdc++-v3/inc lude/backward -I/scratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/src/libstdc++-v3/testsuite/util -fmessage -length=0 -L/scratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/build/hppa-linux-gnu/./libstdc++-v3/src/ .libs -L/scratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/build/hppa-linux-gnu/./libstdc++-v3/src/.libs -L /scratch/packages/gcc/4.2/gcc-4.2-4.2-20070502/build/hppa-linux-gnu/./libiberty -lm -o ./complex1.exe (timeout = 600) /usr/bin/ld: error in /tmp/cci9XkZD.o(.eh_frame); no .eh_frame_hdr table will be created. output is: /usr/bin/ld: error in /tmp/cci9XkZD.o(.eh_frame); no .eh_frame_hdr table will be created. FAIL: g++.dg/other/complex1.C (test for excess errors) Excess errors: /usr/bin/ld: error in /tmp/cci9XkZD.o(.eh_frame); no .eh_frame_hdr table will be created.
Subject: Re: New: [regression] ld errors: no .eh_frame_hdr table will be created. > building the gcc-4.2.0 RC2 with binutils_20070426 on Debian unstable, some > hundred testcases fail like: 2.17.50 20070116 is ok. Do you have a build using a more recent binutils that was ok? Dave
checking with a 20070210 build, starting the build now; will have results tomorrow; I didn't build newer snapshots on hppa.
Subject: Re: New: [regression] ld errors: no .eh_frame_hdr table will be created. > > building the gcc-4.2.0 RC2 with binutils_20070426 on Debian unstable, some > > hundred testcases fail like: I think this was introduced by the following change: 2007-04-24 Alan Modra <amodra@bigpond.net.au> * elf-eh-frame.c (_bfd_elf_discard_section_eh_frame): Warn if eh_frame_hdr table won't be created. We use an indirect pc-relative encoding for global and code symbols. This is somewhat unusual and possibly the cause of the problem. The goal here was to get rid of all dynamic relocations. Dave
The patch merely warns about a problem that existed before. It's a real problem too. C++ exception handling will be slow for you if you have .eh_frame_hdr without the lookup table.
Subject: Re: [regression] ld errors: no .eh_frame_hdr table will be created. > ------- Additional Comments From amodra at bigpond dot net dot au 2007-05-02 23:48 ------- > The patch merely warns about a problem that existed before. It's a real problem > too. C++ exception handling will be slow for you if you have .eh_frame_hdr > without the lookup table. I don't think anything more can be done at the gcc end. The most likely problem is _bfd_elf_discard_section_eh_frame can't cope with the indirect pc-relative encoding that we use for the personality function. Dave
Subject: Re: [regression] ld errors: no .eh_frame_hdr table will be created. > I don't think anything more can be done at the gcc end. The most likely > problem is _bfd_elf_discard_section_eh_frame can't cope with the indirect > pc-relative encoding that we use for the personality function. I see a problem is here: /* Ensure we have a reloc here, against a global symbol. */ In our case, the reloc is against a local symbol. So, cie->personality doesn't get set and REQUIRE (cie->personality) fails. Dave
If that is the only problem, it's easily fixed. cie->personality is only used when checking that two CIEs are equivalent. Since we are fairly late in the link process here, you could use a bfd_vma set to the final symbol value instead of a struct elf_link_hash_entry * for cie->personality. That ought to work for local syms as well as global.
Created attachment 1754 [details] handle local syms
Subject: Re: [regression] ld errors: no .eh_frame_hdr table will be created. > ------- Additional Comments From amodra at bigpond dot net dot au 2007-05-05 22:50 ------- > Created an attachment (id=1754) > --> (http://sourceware.org/bugzilla/attachment.cgi?id=1754&action=view) > handle local syms This works for me. The ld testsuite is clean and I don't see any problems in gcc builds and checks using it on hppa-unknown-linux-gnu. Thanks, Dave
FYI, this appears to fix m68k-elf too. The problem only shows up if you rebuild libstdc++; in eh_personality.o ".long __gxx_personality_v0" becomes a relocation against the section .text.__gxx_personality_v0 after assembly. I'm not sure gas is correct in making that transformation for a locally defined global symbol, but there you have it.
http://sourceware.org/ml/binutils-cvs/2007-05/msg00052.html
Hmm. I'll bet hppa is doing the same as m68k-elf. Looks like both have buggy tc_fix_adjustable implementations. Reducing relocs against globals to relocs against section syms can break ELF shared libraries, since you must be able to override a function or variable in the library with one in the executable or another shared lib. What's more, there is no point in reducing to a section sym because you're going to output a global sym anyway.
From tc-m68k.h: /* Target *-*-elf implies an embedded target. No shared libs. *-*-uclinux also requires special casing to prevent GAS from generating unsupported R_68K_PC16 relocs. */ #define EXTERN_FORCE_RELOC \ ((strcmp (TARGET_OS, "elf") != 0) && (strcmp (TARGET_OS, "uclinux") != 0))
I guess I shouldn't comment late at night. I'd forgotten about EXTERN_FORCE_RELOC and the S_FORCE_RELOC check in adjust_reloc_syms. ie. the hppa-linux tc_fix_adjustable is fine.