I'd have reported the following bug on bugs.opensolaris.org, but found no
category for the assembler (which is plausible given that is isn't part of
an open consolidation yet), so I'll try here:
I've recently tried to build GCC 4.4 svn mainline on Solaris Express,
snv_101 with the native assembler, but with GNU ld 2.19. When trying to
link the 32-bit libffi.so, gld chokes on one of the object files, as
reported in
http://sourceware.org/bugzilla/show_bug.cgi?id=7023
The problem can be seen like so:
% touch v9.s
% as -V -Qy -s -K PIC -xarch=v8plus -o v9.o v9.s
% /usr/sfw/bin/gld -V -G -dy -z text -Qy -o v9.so v9.o
GNU ld version 2.15
Supported emulations:
elf32_sparc
elf64_sparc
v9.o: could not read symbols: Memory exhausted
% /usr/sfw/bin/greadelf -S 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)
The .symtab section has a size of 0, and Inf is 1, which causes gld to try
and allocate 0 - 1 -> 0xFFFFFFFF bytes of memory.
gas 2.19 doesn't show this behavior. While gld is wrong to attempt this
allocation, Sun as seems to be broken too, and it would be good to fix
this.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
