I just tried to bootstrap current gcc mainline on Solaris 11/SPARC, but the bootstrap failed linking the 32-bit libffi.so. This happens both with ld 2.19 and current CVS mainline: % /vol/gcc/obj/binutils-2.19.50/ld/ld-new -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy -o .libs/libffi.so.4.0.1 /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/crti.o /usr/ccs/lib/values-Xa.o /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/crtbegin.o -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/sparc/.libs/ffi.o src/sparc/.libs/v8.o src/sparc/.libs/v9.o -lc -soname libffi.so.4 -lgcc_s -lgcc_s /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/crtend.o /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/crtn.o GNU ld (GNU Binutils) 2.19.50.20081111 Supported emulations: elf32_sparc elf64_sparc src/sparc/.libs/v9.o: could not read symbols: Memory exhausted This object file only contains a .comment section: % objdump -h src/sparc/.libs/v9.o src/sparc/.libs/v9.o: file format elf32-sparc Sections: Idx Name Size VMA LMA File off Algn 0 .comment 0000003b 00000000 00000000 00000059 2**0 CONTENTS, READONLY I haven't yet tracked this down further, but I'm pretty sure I could bootstrap gcc with older GNU ld versions in the past, so this is most likely a regression. I tried to look for unusually large allocations via malloc with apptrace and truss -u, but found nothing of this sort.
Subject: Re: New: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted Some additional investigation revealed the following: * bfd_set_error (bfd_error_no_memory) is called here: #0 bfd_set_error (error_tag=bfd_error_no_memory) at /vol/gnu/src/binutils/binutils-2.19/bfd/bfd.c:425 #1 0x00046e20 in bfd_malloc2 (nmemb=4294967295, size=68719476720) at /vol/gnu/src/binutils/binutils-2.19/bfd/libbfd.c:199 #2 0x00064968 in bfd_elf_get_elf_syms (ibfd=0x15c8b0, symtab_hdr=0x0, symcount=4294967295, symoffset=1, intsym_buf=0x0, extsym_buf=0x0, extshndx_buf=0x0) at /vol/gnu/src/binutils/binutils-2.19/bfd/elf.c:390 #3 0x00078164 in bfd_elf_link_add_symbols (abfd=0x15c8b0, info=0x122920) at /vol/gnu/src/binutils/binutils-2.19/bfd/elflink.c:3666 #4 0x00027638 in load_symbols (entry=0x1230b0, place=0xffbff240) at /vol/gnu/src/binutils/binutils-2.19/ld/ldlang.c:2573 #5 0x000280dc in open_input_bfds (s=0x1230b0, force=0) at /vol/gnu/src/binutils/binutils-2.19/ld/ldlang.c:3002 #6 0x0002dd60 in lang_process () at /vol/gnu/src/binutils/binutils-2.19/ld/ldlang.c:6073 #7 0x000306f4 in main (argc=34, argv=0xffbff3d4) at /vol/gnu/src/binutils/binutils-2.19/ld/ldmain.c:453 * bfd_elf_get_elf_syms is called with symcount = -1L, which leads to the allocation failure observed * That value of symcount is computed in bfd/elflink.c (elf_link_add_object_symbols): at line 3674 (current binutils mainline) symcount =0, hdr->sh_info = 1 -> extsymcount = -1LL hdr is like this at this point: (gdb) p hdr $6 = (Elf_Internal_Shdr *) 0x213d00 (gdb) p *$6 $7 = {sh_name = 11, sh_type = 2, sh_flags = 2, sh_addr = 0, sh_offset = 88, sh_size = 0, sh_link = 3, sh_info = 1, sh_addralign = 1, sh_entsize = 16, bfd_section = 0x0, contents = 0x0} further investigation with readelf gives: % readelf -S src/sparc/.libs/v9.o There are 5 section headers, starting at offset 0x94: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .shstrtab STRTAB 00000000 000034 000024 00 0 0 1 [ 2] .symtab SYMTAB 00000000 000058 000000 10 A 3 1 1 [ 3] .strtab STRTAB 00000000 000058 000001 00 A 0 0 1 [ 4] .comment PROGBITS 00000000 000059 00003b 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) I'm not sure how best to fix this: the following hack worked for me: Index: bfd/elflink.c =================================================================== RCS file: /cvs/src/src/bfd/elflink.c,v retrieving revision 1.315 diff -u -p -r1.315 elflink.c --- bfd/elflink.c 20 Oct 2008 10:57:33 -0000 1.315 +++ bfd/elflink.c 11 Nov 2008 22:32:25 -0000 @@ -3671,7 +3671,10 @@ elf_link_add_object_symbols (bfd *abfd, } else { - extsymcount = symcount - hdr->sh_info; + if (symcount > 0) + extsymcount = symcount - hdr->sh_info; + else + extsymcount = symcount; extsymoff = hdr->sh_info; }
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 2] .symtab SYMTAB 00000000 000058 000000 10 A 3 1 1 Size of zero but sh_info of one?? That is quite broken. How was this object file created? If by gas, we have some other bug to fix.
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted amodra at bigpond dot net dot au writes: > ------- Additional Comments From amodra at bigpond dot net dot au 2008-11-11 23:46 ------- > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 2] .symtab SYMTAB 00000000 000058 000000 10 A 3 1 1 > > Size of zero but sh_info of one?? That is quite broken. How was this object > file created? If by gas, we have some other bug to fix. By Sun as in a gcc mainline build: % /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/xgcc -B/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -I. -I/vol/gcc/src/gcc-dist/libffi/include -Iinclude -I/vol/gcc/src/gcc-dist/libffi/src -g -O2 -c /vol/gcc/src/gcc-dist/libffi/src/sparc/v9.S -fPIC -DPIC -o src/sparc/.libs/v9.o -v /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/as -V -Qy -s -K PIC -xarch=v8plus -o src/sparc/.libs/v9.o v9.s /usr/bin/as: Sun Compiler Common 12 SunOS_sparc snv_93 06/19/2008 v9.s is empty except for comments. If I configure with gas 2.19, that is invoked as /vol/gcc/lib/gas-2.19 --gdwarf2 -v -V -Qy -s -K PIC -xarch=v8plus -o v9.o v9.s GNU assembler version 2.19 (sparc-sun-solaris2.10) using BFD version (GNU Binutils) 2.19 and readelf -S gives There are 7 section headers, starting at offset 0x60: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 000034 000000 00 AX 0 0 1 [ 2] .data PROGBITS 00000000 000034 000000 00 WA 0 0 1 [ 3] .bss NOBITS 00000000 000034 000000 00 WA 0 0 1 [ 4] .shstrtab STRTAB 00000000 000034 00002c 00 0 0 1 [ 5] .symtab SYMTAB 00000000 000178 000040 10 6 4 4 [ 6] .strtab STRTAB 00000000 0001b8 000001 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) But even if Sun as is broken here (and I can file a bug report for that), gld shouldn't try to allocate an infinite amount of memory. Rainer
http://sourceware.org/ml/binutils-cvs/2008-11/msg00052.html http://sourceware.org/ml/binutils/2008-11/msg00123.html
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted amodra at bigpond dot net dot au writes: > http://sourceware.org/ml/binutils-cvs/2008-11/msg00052.html > http://sourceware.org/ml/binutils/2008-11/msg00123.html I've checked the oldest version of Sun as available to me, and it behaves just the same: % uname -a SunOS antipasto 5.8 Generic_117350-46 sun4u sparc % touch v9.s % as -V -Qy -s -K PIC -xarch=v8plus -o v9.o v9.s as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch 114802-02 % readelf -S v9.o There are 5 section headers, starting at offset 0x9c: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .shstrtab STRTAB 00000000 000034 000024 00 0 0 1 [ 2] .symtab SYMTAB 00000000 000058 000000 10 A 3 1 1 [ 3] .strtab STRTAB 00000000 000058 000000 00 A 0 0 1 [ 4] .comment PROGBITS 00000000 000058 000044 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) The gld problem exists at least as far back as binutils 2.15: % /usr/sfw/bin/gld -V -G -dy -z text -o v9.so v9.o GNU ld version 2.15 Supported emulations: elf32_sparc elf64_sparc v9.o: could not read symbols: Memory exhausted It may be unusual to build gcc with Sun as and GNU ld, but it should work nonetheless. Btw., I've reported the Sun as problem here: http://mail.opensolaris.org/pipermail/tools-compilers/2008-November/000436.html but have not yet received a response. Rainer
> It may be unusual to build gcc with Sun as and GNU ld, but it should work > nonetheless. Not really, there are more annoying problems and that's discouraged: http://gcc.gnu.org/install/specific.html#x-x-solaris2 Do not waste your time on this I'd think.
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted ebotcazou at gcc dot gnu dot org writes: > Not really, there are more annoying problems and that's discouraged: > http://gcc.gnu.org/install/specific.html#x-x-solaris2 Unfortunately, the relevant section We recommend the use of GNU binutils 2.14 or later, or the vendor tools (Sun as, Sun ld). Note that your mileage may vary if you use a combination of the GNU tools and the Sun tools: while the combination GNU as + Sun ld should reasonably work, the reverse combination Sun as + GNU ld is known to cause memory corruption at runtime in some cases for C++ programs. is relatively vague. I'll probably have to look up when it was added to get some details. Anyway, the two other cases I tried (GNU as + Sun ld and GNU as + GNU ld) worked resonably well when comparing testsuite results to the Sun as + Sun ld baseline. Only the Sun as + GNU ld case broke in several respects: this PR + ld/7027 + GCC PRs libgomp/38086 and libstdc++/38092. > Do not waste your time on this I'd think. Unfortunately, I need at least one configuration as a baseline for a proper fix for GCC PR bootstrap/33100. Rainer
> Unfortunately, the relevant section > > We recommend the use of GNU binutils 2.14 or later, or the vendor tools > (Sun as, Sun ld). Note that your mileage may vary if you use a combination > of the GNU tools and the Sun tools: while the combination GNU as + Sun ld > should reasonably work, the reverse combination Sun as + GNU ld is known to > cause memory corruption at runtime in some cases for C++ programs. > > is relatively vague. What's vague exactly? > Anyway, the two other cases I tried (GNU as + Sun ld and GNU as + GNU ld) > worked resonably well when comparing testsuite results to the Sun as + Sun > ld baseline. Only the Sun as + GNU ld case broke in several respects: this > PR + ld/7027 + GCC PRs libgomp/38086 and libstdc++/38092. Yes, it's effectively unsupported, hence my message. > Unfortunately, I need at least one configuration as a baseline for a proper > fix for GCC PR bootstrap/33100. I don't see why, you don't need a baseline for a bootstrap problem.
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted ebotcazou at gcc dot gnu dot org writes: > > Unfortunately, the relevant section > > > > We recommend the use of GNU binutils 2.14 or later, or the vendor tools > > (Sun as, Sun ld). Note that your mileage may vary if you use a combination > > of the GNU tools and the Sun tools: while the combination GNU as + Sun ld > > should reasonably work, the reverse combination Sun as + GNU ld is known to > > cause memory corruption at runtime in some cases for C++ programs. > > > > is relatively vague. > > What's vague exactly? the last half-sentence about memory corruption: no details, no PR or whatever. > > Anyway, the two other cases I tried (GNU as + Sun ld and GNU as + GNU ld) > > worked resonably well when comparing testsuite results to the Sun as + Sun > > ld baseline. Only the Sun as + GNU ld case broke in several respects: this > > PR + ld/7027 + GCC PRs libgomp/38086 and libstdc++/38092. > > Yes, it's effectively unsupported, hence my message. Although the bugs seem to be easily fixed Besides, breakage wide into the bootstraps seems like a poor way to convey that information ;-) > > Unfortunately, I need at least one configuration as a baseline for a proper > > fix for GCC PR bootstrap/33100. > > I don't see why, you don't need a baseline for a bootstrap problem. My change needs to be tested with both Sun ld and GNU ld since the inclusion of gcc/config/i386/t-crtstuff will become conditional upon a link test, and I need to test all paths: older/broken Sun ld, new/fixed Sun ld and GNU ld. And for the GNU ld case (which I've not tried in a long time if at all) I need a baseline without my change. Rainer
> the last half-sentence about memory corruption: no details, no PR or > whatever. On purpose, the GCC manual is not the right place for that. > Although the bugs seem to be easily fixed Besides, breakage wide into the > bootstraps seems like a poor way to convey that information ;-) You'll get a non-working toolchain in all cases... > My change needs to be tested with both Sun ld and GNU ld since the > inclusion of gcc/config/i386/t-crtstuff will become conditional upon a link > test, and I need to test all paths: older/broken Sun ld, new/fixed Sun ld > and GNU ld. And for the GNU ld case (which I've not tried in a long time > if at all) I need a baseline without my change. Use GNU as.
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted ebotcazou at gcc dot gnu dot org writes: > > the last half-sentence about memory corruption: no details, no PR or > > whatever. > > On purpose, the GCC manual is not the right place for that. Agreed: I'll have to lookup the details myself. > > Although the bugs seem to be easily fixed Besides, breakage wide into the > > bootstraps seems like a poor way to convey that information ;-) > > You'll get a non-working toolchain in all cases... I'm not sure yet: the GCC PRs can be worked around by using --disable-symvers for now, but that should be automatic. This PR can (and should) be fixed both in Sun as and GNU ld, and PR ld/7027 should be worked around in GNU ld either, just as in the similar 32-bit case. > > My change needs to be tested with both Sun ld and GNU ld since the > > inclusion of gcc/config/i386/t-crtstuff will become conditional upon a link > > test, and I need to test all paths: older/broken Sun ld, new/fixed Sun ld > > and GNU ld. And for the GNU ld case (which I've not tried in a long time > > if at all) I need a baseline without my change. > > Use GNU as. Indeed: that's what I'll do for the moment. Rainer
Subject: Re: ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted I've now filed a bug against Sun as: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6774496 While further discussion on the tools-compilers@opensolaris.org thread http://mail.opensolaris.org/pipermail/tools-compilers/2008-November/000436.html has produced some evidence that the Sun assembler is correct as mandated by the System V GABI, Sun agreed to fix this. Rainer
CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2012-05-16 03:35:29 Modified files: bfd : ChangeLog elf.c Log message: PR ld/13962 PR ld/7023 * elf.c (bfd_section_from_shdr): Fail when .dynsym sh_info is out of range. As a special case, fix sh_info for zero sh_size. Do the same for .symtab. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5682&r2=1.5683 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf.c.diff?cvsroot=src&r1=1.553&r2=1.554