Re: Possible Linker Bug with static template member on Solaris

[Axel Habermann]

(I am forwarding this to the list, because I forgot to CC the list on my 
reply.)

Ian Lance Taylor wrote:

> Axel Habermann <address@hidden> writes:
>
>  
>
> > 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
> >    
>
> Good analysis.  This sounds like a compiler bug.  If the compiler uses
> .gnu.linkonce.b*, it is responsible for making sure that the section
> has no actual contents.  Can you find out what is causing the compiler
>  
The compiler might be the one who causes the error, but the behaviour of 
ld.so (or whoever
loads the program into memory on Solaris) is faulty also. I always 
thought that there is nothing
supposed to be in memory newly allocated by sbrk.

> to create that section?  Then looked at the generated assembler file,
> and see how the compiler is using the .section pseudo-op, and what it
> is putting in the section.
>  
Ok, here we go.

I use a static member in a template as follows:


template<class ParamType = bool>
class InternalNotificator {

  static map<notificationTypes, InternalNotificator<ParamType> * > * 
notificatorMap;

  ...
};

template<class ParamType>
map<notificationTypes, InternalNotificator<ParamType> * > *
InternalNotificator<ParamType>::notificatorMap;


this is assembled by the compiler (g++ 3.4.0) to

      .weak   _ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE
      .section        
".gnu.linkonce.b._ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE",#alloc,#write
      .align 4
      .type   
_ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE, #object
      .size   _ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE, 4
_ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE:
      .skip 4


g++ calls the gnu assembler:

/net/solaris/binutils-2.14/bin/as -V -Qy -s -K PIC -xarch=v8 -o 
StateMonitor.o /var/tmp//ccOI4Yi1.s
GNU assembler version 2.14 (sparc-sun-solaris2.8) using BFD version 2.14 
20030612

and finally objdump sees this as

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


Now this looks more like an assembler bug to me.

Btw.: Trying to use binutils-2.15 to solve the problem resulted in SEGV 
in ld in early stages of compilation, but this might be caused by a 
totally unrelated problem.

Another note: the problem does not exist on Linux. There, the .bss is 
ALLOC, even when an object file with the static template member is 
linked in.
This is the compiler output on Linux (same g++ 3.4.0)

      .weak   _ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE
      .section        
.gnu.linkonce.b._ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE,"aw",@nobits
      .align 4
      .type   
_ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE, @object
      .size   _ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE, 4
_ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE:
      .zero   4

Axel