bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Mem


From: ro at TechFak dot Uni-Bielefeld dot DE
Subject: [Bug ld/7023] ld is unable to link 32 bit libffi.so on gcc mainline: Memory exhausted
Date: 12 Nov 2008 18:16:22 -0000

------- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE  
2008-11-12 18:16 -------
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/bugzilla/show_bug.cgi?id=7023

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]