Possible Linker Bug with static template member on Solaris

[Axel Habermann]

Hi,

I think I discovered a bug in either the Linker (ld), the Compiler (g++) 
or the runtime system of Solaris.
I am using binutils 2.14 and gcc-3.4.0 on Solaris 8. When I link an 
executable using libthread.so with
code containing at least one static template member, I get an exception 
from my thread abstraction
library which is triggered by uninitialized data used by libthread.

Intense debugging revealed that libthread is using memory obtained with 
a call to sbrk which should
be all zeroes and it relies on the memory being zeroed.

If the code is linked with code having static template members, the 
memory returned by sbrk is not
zeroes, but contains the content of the sections following the .bss in 
the executable. I was able to find
the content of the sections .comment and .stabs.indexstr in the memory 
area directly following the
.bss segment (in memory of the just started process).

Further investigation revealed that the reason for the "dirt" being in 
the memory is that the executable
contains a section .bss as follows

21 .bss          00000100  000479c8  000479c8  000279c8  2**3
                 CONTENTS, ALLOC, LOAD, DATA

whereas in the correct case (no "dirt" following the .bss section in memory)

21 .bss          000000f8  0002b328  0002b328  0000b328  2**3
                 ALLOC

The "dirt" case seems to be triggered by the presence of static template 
members in one of the
linked object files. A static template member is shown as follows by objdump

511 
.gnu.linkonce.b._ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE 
00000004  00000000  00000000  000533b8  2**2
                 CONTENTS, ALLOC, LOAD, DATA, LINK_ONCE_DISCARD

This obviously makes the linker include a .bss section content and 
change the flags for .bss from
ALLOC to CONTENTS, ALLOC, LOAD, DATA. There are many other gnu.linkonce.b.*
elements, but those have either RELOC or READONLY (or both) as 
additional flags.
If the .bss section is marked CONTENTS, ALLOC, LOAD, DATA, the program 
starter (ld.so probably)
appends the content of the following sections (.comment, .stabs.*) to 
the program in memory which in turn
leads to a misbehaviour of libthread.so

I was able to circumvent the problem by writing a linker script which 
puts all of
.gnu.linkonce.b.* into a section other than .bss (the default linker 
script includes .gnu.linkonce.b.* into
.bss). When using the linker script, .bss has ALLOC and the extra 
section created for
.gnu.linkonce.b.* is flagged CONTENTS, ALLOC, LOAD, DATA.

I am not exactly sure if this is a linker or compiler bug, because I 
don't know whether the
flags CONTENTS, ALLOC, LOAD, DATA, LINK_ONCE_DISCARD are correct for this
kind of symbol or not. If they are the correct flags, then the linker is 
to blame. Otherwise the bug
is in the g++ (As a side note: everything wroks when building the gcc 
with the platform linker,
not binutils). Anyway, the behaviour of the program starter seems to be 
buggy also. Even if the
.bss section is present as loadable data, it should not make the program 
loader append the contents
of debugging sections to the loaded program in memory.

Regards,

Axel
--
Xtradyne Technologies AG