[Top][All Lists]

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

Re: Possible Linker Bug with static template member on Solaris

From: Axel Habermann
Subject: Re: Possible Linker Bug with static template member on Solaris
Date: Tue, 15 Jun 2004 17:44:55 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

(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> * > *

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
      .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

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
      .zero   4


reply via email to

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