http://sourceware.org/bugzilla/show_bug.cgi?id=15057
--- Comment #2 from Rainer Orth 2013-01-24
13:16:08 UTC ---
> --- Comment #1 from Alan Modra 2013-01-24 01:40:40
> UTC ---
> Create a link map for one of these failing tests (-Wl,-Map,). Look
> in to see what sections (or data!) are going in to .bss. If you
> find data from a linker script there's your problem, otherwise look at all the
> input objects contributing to .bss to see whether any have a SHT_PROGBITS
> .bss.
> If no input objects, then we might have a bug in the linker when eg. the
> linker created .dynbss is the only section in .bss output section.
Thanks, that helped a lot: with Sun as, several .bss. sections
in the input object files are marked SHT_PROGBITS (I keep forgetting
about those), unlike Solaris/x86 with Sun as.
On Solaris/x86, gcc generates
.section.bss.def,"aw",@nobits
while on Solaris/SPARC we get this instead:
.section".bss.def",#alloc,#write
It turns out that Solaris 10+ as supports the necessary
#nobits/#progbits syntax, while Solaris 9 does not. gcc/
config/sparc/sparc.c (sparc_solaris_elf_asm_named_section) has
/* ??? Handle SECTION_BSS. */
while SECTION_BSS is handled explicitly in gcc/varasm.c
(default_elf_asm_named_section).
After all, a gcc issue.
Thanks for your help resolving it.
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
