GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13

Loren James Rittle rittle@latour.rsch.comm.mot.com
Fri Jul 26 01:26:00 GMT 2002

(Based upon the analysis below, I am CCing gcc-bugs RE PR 7171.  The
 version numbers in the subject line refer to binutils.  Quick
 summary: More C++ test cases fail with binutils pre-2.13 than failed
 with binutils ~2.12.1.  This behavior has been spotted on a wide
 variety of platforms.)

Thank you Jason R Thorpe, Alan Modra and Ian Lance Taylor for the
discussion you held last week on this topic.  Here is what I see when
I build "element_access.exe" on i386-unknown-freebsd4.6 (a newly
failing C++ libstdc++-v3 test case, upon binutils upgrade to pre-2.13
with full rebootstrap of gcc) with -Map:

.rodata         0x08048e80      0x14d
 *(.rodata .rodata.* .gnu.linkonce.r.*)
 .rodata        0x08048e80        0x1 /usr/lib/crt1.o
 *fill*         0x08048e81       0x1f 00
 .rodata        0x08048ea0      0x10f /var/tmp//ccAEn9wX.o
 *fill*         0x08048faf        0x1 00
                0x08048fb0        0xc /var/tmp//ccAEn9wX.o
                0x08048fb0                _ZTISt12out_of_range
                0x08048fbc       0x11 /var/tmp//ccAEn9wX.o
                0x08048fbc                _ZTSSt12out_of_range

Tracing back, I see these entries in "element_access.o":

  [16] .gnu.linkonce.r._ PROGBITS        00000000 008f2c 00000c 00  WA  0   0  4
  [18] .gnu.linkonce.r._ PROGBITS        00000000 008f38 000011 00   A  0   0  1

Based on size of element, it appears that _ZTISt12out_of_range (AKA
``typeinfo for std::out_of_range'') is of interest.  Tracing back from
here, I see this in the g++-produced asm:

        .section        .gnu.linkonce.r._ZTISt12out_of_range,"aw",@progbits

In a source tree configured against an older ld, the same line is
present and the "writeable bit" propagates through to the final
executable built there as well.  However, it doesn't trigger the
report from the system's dynamic ELF loader in that particular test case.

Question (raised only for completeness, I think the answer is ``no''):
is this line from the ldscript wrong?

  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }

Or, is g++ wrong in producing that particular .section line?

From reading gcc sources, I think the .r. in .gnu.linkonce.r.* implies
read-only, thus the conflict would appear to lie in the production
within the compiler.  Spot checking the other type of new test suite
failures, which are all of this form:

ld: ./XYZ.exe: Not enough room for program headers (allocated 6, need 7)

I note that the input object built by g++ has the write bit set on at
least some of the .gnu.linkonce.r.* sections.

We now have reports of this exact failure symptom on (at least):
i686-pc-linux-gnu (PR 7171), sparc-sun-solaris, i386-unknown-freebsd,
alpha-*-netbsd, i386-*-netbsd

I can investigate further but not until Friday afternoon.


More information about the Gcc-bugs mailing list