[Bug c++/16007] New: Use of static template members results in broken executables

[Bug c++/16007] New: Use of static template members results in broken executables

[kiwi at xtradyne dot de]

Hi,

I think I discovered a bug in g++ which leads to misbehaviour in 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 accessed 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 the
described 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.

Discussion with Ian Lance Taylor on the binutils bug list convinced me that it
is a compiler bug, because the .gnu.linkonce.b* sections should never contain
any data.
(As a side note: everything works when building the gcc with the platform
linker, because the Solaris linker puts every .gnu.linkonce.b* section in its
own section in the resulting executable, not disturbing the .bss in any way)

Anyway, the behaviour of the Solaris 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.

How to reproduce (actually, the bug might go unnoticed in many cases as the
"dirt" following the executable's end only disturbs if the first caller(s) to
sbrk expect the memory returned to be zero-initialised. If they zero out the
memory before using it, everything will work fine. libthread.so zeroes out most
of it except some values vital for its operation). To test if the executable has
the problem, run objdump -x on it and look at the attributes for .bss. If they
are not ALLOC but CONTENTS, ALLOC, LOAD, DATA, LINK_ONCE_DISCARD the problem occurs.

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

and elfdump shows this as

Section Header[511]:  sh_name:
.gnu.linkonce.b._ZN19InternalNotificatorI12ChangeRecordE14notificatorMapE
   sh_addr:      0               sh_flags:   [ SHF_WRITE  SHF_ALLOC ]
   sh_size:      0x4             sh_type:    [ SHT_PROGBITS ]
   sh_offset:    0x68398         sh_entsize: 0
   sh_link:      0               sh_info:    0
   sh_addralign: 0x4


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

Regards,

Axel Habermann

-- 
           Summary: Use of static template members results in broken
                    executables
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kiwi at xtradyne dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug c++/16007] Use of static template members results in broken executables

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-06-15 17:12 -------
My take on this issue is that gcc needs to direct the assembler to create the
.gnu.linkonce.b* section with a type of SHT_NOBITS.  In standard SVR4 assembler
.section syntax, the compiler can just use @nobits, as shown at the end of the
original report.  In Solaris assembler .section syntax, I do not know how to do
this; the Solaris assembler manual does not provide any mechanism.

Possible fixes that I see: 1) On Solaris, do not use .gnu.linkonce.b*; 2) If we
are using gas on Solaris, use SVR4 assembler syntax for .section; 3) teach gas
about .gnu.linkonce.b* (not a gcc patch).  Note that options 2 and 3 break if
the users uses the Solaris assembler and the GNU linker.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug c++/16007] Use of static template members results in broken executables

[ian at wasabisystems dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at wasabisystems dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug c++/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug c++/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-06-19 12:15 -------
> Possible fixes that I see: 1) On Solaris, do not use .gnu.linkonce.b*; 2) If we
> are using gas on Solaris, use SVR4 assembler syntax for .section; 3) teach gas
> about .gnu.linkonce.b* (not a gcc patch).  Note that options 2 and 3 break if
> the users uses the Solaris assembler and the GNU linker.

We already have a problem with GNU as + Sun ld (see PR target/15267) so I don't
see a problem with Sun as + GNU ld as a show stopper.  IMHO we only have to make
sure that the compiler works with either complete set of tools.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug c++/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-07-07 10:57 -------
Investigating.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ebotcazou at gcc dot gnu dot|
                   |org                         |
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-07-07 10:57:44
               date|                            |
   Target Milestone|---                         |3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-07-07 13:35 -------
Ian, I think the cleanest fix is to teach gas to set the SHT_NOBITS type on the
.gnu.linkonce.b* sections, like on the .bss section.  Would the following patch
be sufficient?

Index: elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.232
diff -u -p -r1.232 elf.c
--- elf.c       28 Jun 2004 13:57:58 -0000      1.232
+++ elf.c       7 Jul 2004 13:24:42 -0000
@@ -2045,6 +2045,7 @@ bfd_section_from_elf_index (bfd *abfd, u
 static struct bfd_elf_special_section const special_sections[] =
 {
   { ".bss",            4, -2, SHT_NOBITS,   SHF_ALLOC + SHF_WRITE },
+  { ".gnu.linkonce.b",15, -2, SHT_NOBITS,   SHF_ALLOC + SHF_WRITE },
   { ".comment",        8,  0, SHT_PROGBITS, 0 },
   { ".data",           5, -2, SHT_PROGBITS, SHF_ALLOC + SHF_WRITE },
   { ".data1",          6,  0, SHT_PROGBITS, SHF_ALLOC + SHF_WRITE },

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-07-13 03:28 -------
Yes, I think that patch should work for GNU as plus GNU ld.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-29 19:09 -------
Postponed until GCC 3.4.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-09-07 14:08 -------
The problem should be fixed with binutils 2.15 CVS (and binutils mainline).  See
http://sources.redhat.com/binutils for how to obtain the sources (the CVS tag is
binutils-2_15-branch).  I don't know of CVS snapshots made from the release
branch for binutils.

I'm not sure what to do for the combination Sun assembler + GNU linker.  Ian's
suggestion #1 seems a bit extreme to me.  Perhaps documenting that it is not
supported on Solaris/SPARC would be sufficient; after all, that's really a weird
combination and I'm not sure it is even supposed to work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-06 11:01 -------
Subject: Bug 16007

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	ebotcazou@gcc.gnu.org	2004-10-06 11:01:44

Modified files:
	gcc            : ChangeLog 
	gcc/doc        : install.texi 

Log message:
	PR target/16007
	* doc/install.texi (*-*-solaris2*): Mention potential problem
	with Sun assembler + GNU linker and C++ programs.
	Document status of binutils 2.15 release.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5761&r2=2.5762
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/install.texi.diff?cvsroot=gcc&r1=1.319&r2=1.320



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-06 11:06 -------
Subject: Bug 16007

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	ebotcazou@gcc.gnu.org	2004-10-06 11:05:59

Modified files:
	gcc            : ChangeLog 
	gcc/doc        : install.texi 

Log message:
	PR target/16007
	* doc/install.texi (*-*-solaris2*): Mention potential problem
	with Sun assembler + GNU linker and C++ programs.
	Document status of binutils 2.15 release.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.643&r2=2.2326.2.644
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/install.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.248.4.27&r2=1.248.4.28



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-06 11:10 -------
Subject: Bug 16007

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	ebotcazou@gcc.gnu.org	2004-10-06 11:10:04

Modified files:
	gcc            : ChangeLog 
	gcc/doc        : install.texi 

Log message:
	PR target/16007
	* doc/install.texi (*-*-solaris2*): Mention potential problem
	with Sun assembler + GNU linker and C++ programs.
	Document status of binutils 2.15 release.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1020&r2=1.16114.2.1021
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/install.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.151.2.53&r2=1.151.2.54



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-06 11:13 -------
Suspended until after a new binutils release with the fix is out.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-01 00:45 -------
Postponed until GCC 3.4.4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.4                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007

[Bug target/16007] Use of static template members results in broken executables

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-05-31 16:37 -------
Binutils 2.16 have been released with the fix.  They work fine in conjunction
with the 3.4.x compiler and above, so closing as fixed in most recent 3.4.x release.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16007