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

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

[Loren James Rittle]

It was recently announced that a branch was created for the
forthcoming FSF binutils 2.13 release.  In either that message or
another posted soon afterwards, it was mentioned that *now* is the
time to test/report on issues.  Here is my current regression report:

Zero regressions in the binutils testsuite proper on
i386-unknown-freebsd4.6 (with both no patches and a one-liner related
to "branding" which is in our system copy of binutils).

Frequently, I bootstrap GCC mainline on i386-unknown-freebsd4.6.  I
had been bootstrapping against binutils 2.12.1 20020517.  After
upgrading to the pre-2.13 branch, 2.12.90 20020717, I re-bootstrapped
GCC from scratch and saw these new failures (not necessarily
indicative of a binutils bug):

/usr/libexec/ld-elf.so.1: ./element_access.exe: too few PT_LOAD segments
[... 37 additional, similar new failures in g++.log ...]

ld: ./vbase8-10.exe: Not enough room for program headers (allocated 6, need 7)
[... 1 additional, similar new failures in g++.log and 2 additional, similar
 which pre-existed this binutils upgrade but do not appear in FSF 2.11.X...]

(Regarding the second error message, I have noted others posting
reports of it to the gcc DejaGNU.)

The last time I tested binutils mainline (around mid-May), I saw a
similar error profile but hoped to look into it further before
reporting it.  However, I usually hack on the C++ library not this
level of the tool chain thus I'm a fish out of water...

Regards,
Loren

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

[Alan Modra]

On Thu, Jul 18, 2002 at 09:09:27PM -0500, Loren James Rittle wrote:
> /usr/libexec/ld-elf.so.1: ./element_access.exe: too few PT_LOAD segments
> [... 37 additional, similar new failures in g++.log ...]

Well, that's the FreeBSD dynamic loader comlaining.  You'll need to
debug this a little further to find out why..

> ld: ./vbase8-10.exe: Not enough room for program headers (allocated 6, need 7)
This usually indicates a problem with linker scripts, or section
attributes.  For example, if we have a simple two segment layout
with a read-only segment followed by a read-write segment, then
the linker script (and orphan section placement code) should
place all ro sections before rw sections.  If something goes
wrong and we have a rw section being placed in the middle of the
ro sections, then we would need 4 segments, ro, rw, ro, rw.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Jason R Thorpe]

On Thu, Jul 18, 2002 at 09:09:27PM -0500, Loren James Rittle wrote:

 > upgrading to the pre-2.13 branch, 2.12.90 20020717, I re-bootstrapped
 > GCC from scratch and saw these new failures (not necessarily
 > indicative of a binutils bug):
 > 
 > /usr/libexec/ld-elf.so.1: ./element_access.exe: too few PT_LOAD segments
 > [... 37 additional, similar new failures in g++.log ...]

I have been seeing roughly exactly the same problem for some time now
on i386-netbsdelf and alpha-netbsd (I do my gcc-current testing with
a binutils-current of the same vintage).  It has me completely stumped.

I actually brought it up here on the list at one point:

	http://sources.redhat.com/ml/binutils/2002-05/msg00543.html

Note I do NOT see this problem on sparc-netbsdelf.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Alan Modra]

On Fri, Jul 19, 2002 at 10:11:39AM -0700, Jason R Thorpe wrote:
> On Thu, Jul 18, 2002 at 09:09:27PM -0500, Loren James Rittle wrote:
> 
>  > upgrading to the pre-2.13 branch, 2.12.90 20020717, I re-bootstrapped
>  > GCC from scratch and saw these new failures (not necessarily
>  > indicative of a binutils bug):
>  > 
>  > /usr/libexec/ld-elf.so.1: ./element_access.exe: too few PT_LOAD segments
>  > [... 37 additional, similar new failures in g++.log ...]
> 
> I have been seeing roughly exactly the same problem for some time now
> on i386-netbsdelf and alpha-netbsd (I do my gcc-current testing with
> a binutils-current of the same vintage).  It has me completely stumped.
> 
> I actually brought it up here on the list at one point:
> 
> 	http://sources.redhat.com/ml/binutils/2002-05/msg00543.html

That's interesting.  Perhaps "readelf -S" on a bad binary might show
something.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Jason R Thorpe]

On Sat, Jul 20, 2002 at 09:53:39AM +0930, Alan Modra wrote:

 > That's interesting.  Perhaps "readelf -S" on a bad binary might show
 > something.

Here's one from my Alpha system:

There are 38 section headers, starting at offset 0x200610:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         00000001200001c8  000001c8
       0000000000000017  0000000000000000   A       0     0     1
  [ 2] .note.netbsd.iden NOTE             00000001200001e0  000001e0
       0000000000000018  0000000000000000   A       0     0     4
  [ 3] .hash             HASH             00000001200001f8  000001f8
       0000000000000660  0000000000000008   A       4     0     8
  [ 4] .dynsym           DYNSYM           0000000120000858  00000858
       0000000000000690  0000000000000018   A       5     1     8
  [ 5] .dynstr           STRTAB           0000000120000ee8  00000ee8
       0000000000000267  0000000000000000   A       0     0     1
  [ 6] .rela.dyn         RELA             0000000120001150  00001150
       0000000000000090  0000000000000018   A       4     0     8
  [ 7] .rela.plt         RELA             00000001200011e0  000011e0
       0000000000000468  0000000000000018   A       4    14     8
  [ 8] .init             PROGBITS         0000000120001660  00001660
       0000000000000170  0000000000000000  AX       0     0     32
  [ 9] .text             PROGBITS         00000001200017e0  000017e0
       0000000000038f60  0000000000000000  AX       0     0     32
  [10] .fini             PROGBITS         000000012003a740  0003a740
       00000000000000d0  0000000000000000  AX       0     0     32
  [11] .rodata           PROGBITS         000000012003a810  0003a810
       0000000000002d60  0000000000000000  WA       0     0     8
  [12] .eh_frame_hdr     PROGBITS         000000012003d570  0003d570
       000000000000167c  0000000000000000   A       0     0     4
  [13] .data             PROGBITS         0000000120040000  00040000
       0000000000000070  0000000000000000  WA       0     0     8
  [14] .eh_frame         PROGBITS         0000000120040070  00040070
       0000000000006514  0000000000000000  WA       0     0     8
  [15] .gcc_except_table PROGBITS         0000000120046584  00046584
       00000000000019bc  0000000000000000  WA       0     0     4
  [16] .dynamic          DYNAMIC          0000000120047f40  00047f40
       0000000000000170  0000000000000010  WA       5     0     8
  [17] .ctors            PROGBITS         00000001200480b0  000480b0
       0000000000000030  0000000000000000  WA       0     0     8
  [18] .dtors            PROGBITS         00000001200480e0  000480e0
       0000000000000020  0000000000000000  WA       0     0     8
  [19] .jcr              PROGBITS         0000000120048100  00048100
       0000000000000008  0000000000000000  WA       0     0     8
  [20] .plt              PROGBITS         0000000120048108  00048108
       0000000000000254  0000000000000020 WAX       0     0     8
  [21] .got              PROGBITS         0000000120048360  00048360
       0000000000001210  0000000000000000  WA       0     0     8
  [22] .sdata            PROGBITS         0000000120049570  00049570
       00000000000001af  0000000000000000 WAp       0     0     8
  [23] .sbss             NOBITS           0000000120049720  00049720
       0000000000000148  0000000000000000 WAp       0     0     8
  [24] .bss              NOBITS           0000000120049870  00049728
       0000000000001e70  0000000000000000  WA       0     0     16
  [25] .comment          PROGBITS         0000000000000000  00049728
       00000000000006d9  0000000000000000           0     0     1
  [26] .debug_aranges    PROGBITS         0000000000000000  00049e01
       00000000000049a0  0000000000000000           0     0     1
  [27] .debug_pubnames   PROGBITS         0000000000000000  0004e7a1
       000000000001252c  0000000000000000           0     0     1
  [28] .debug_info       PROGBITS         0000000000000000  00060ccd
       000000000013af61  0000000000000000           0     0     1
  [29] .debug_abbrev     PROGBITS         0000000000000000  0019bc2e
       000000000000d492  0000000000000000           0     0     1
  [30] .debug_line       PROGBITS         0000000000000000  001a90c0
       000000000002707c  0000000000000000           0     0     1
  [31] .debug_frame      PROGBITS         0000000000000000  001d0140
       0000000000009a20  0000000000000000           0     0     8
  [32] .debug_str        PROGBITS         0000000000000000  001d9b60
       0000000000024f43  0000000000000001  MS       0     0     1
  [33] .ident            PROGBITS         0000000000000000  001feaa3
       0000000000000039  0000000000000000           0     0     1
  [34] .debug_ranges     PROGBITS         0000000000000000  001feadc
       00000000000019e0  0000000000000000           0     0     1
  [35] .shstrtab         STRTAB           0000000000000000  002004bc
       0000000000000151  0000000000000000           0     0     1
  [36] .symtab           SYMTAB           0000000000000000  00200f90
       0000000000009ca8  0000000000000018          37    9b     8
  [37] .strtab           STRTAB           0000000000000000  0020ac38
       000000000000e97b  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Note the .rodata section:

  [11] .rodata           PROGBITS         000000012003a810  0003a810
       0000000000002d60  0000000000000000  WA       0     0     8

It certainly doesn't seem correct that .rodata is getting "WRITE" set.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Alan Modra]

On Fri, Jul 19, 2002 at 05:51:28PM -0700, Jason R Thorpe wrote:
> It certainly doesn't seem correct that .rodata is getting "WRITE" set.

Exactly.  Fix this problem and I reckon all the other symptoms will
disappear.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Jason R Thorpe]

On Sat, Jul 20, 2002 at 10:50:58AM +0930, Alan Modra wrote:

 > On Fri, Jul 19, 2002 at 05:51:28PM -0700, Jason R Thorpe wrote:
 > > It certainly doesn't seem correct that .rodata is getting "WRITE" set.
 > 
 > Exactly.  Fix this problem and I reckon all the other symptoms will
 > disappear.

A hint of possible starting points would be helpful...

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Alan Modra]

On Fri, Jul 19, 2002 at 06:46:09PM -0700, Jason R Thorpe wrote:
> On Sat, Jul 20, 2002 at 10:50:58AM +0930, Alan Modra wrote:
> 
>  > On Fri, Jul 19, 2002 at 05:51:28PM -0700, Jason R Thorpe wrote:
>  > > It certainly doesn't seem correct that .rodata is getting "WRITE" set.
>  > 
>  > Exactly.  Fix this problem and I reckon all the other symptoms will
>  > disappear.
> 
> A hint of possible starting points would be helpful...

Check all object files involved in the link, including libraries and
startup files, for a RW .rodata section.  I'm guessing you'll find one,
indicating an assembler or more likely, source problem.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Jason R Thorpe]

On Sat, Jul 20, 2002 at 11:22:54AM +0930, Alan Modra wrote:

 > Check all object files involved in the link, including libraries and
 > startup files, for a RW .rodata section.  I'm guessing you'll find one,
 > indicating an assembler or more likely, source problem.

That's what I figured.  No .rodata* sections with the "W" bit set in
any of:

	crt0.o
	crtbegin.o
	append.o (the test program)
	libc.a (or libc.so)
	libm.a (or libm.so)
	libgcc.a
	libstdc++.a
	crtend.o

The problem occurs when the program is linked statically, as well, but
the dynamic linker isn't invokved, so it doesn't croak.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Ian Lance Taylor]

Jason R Thorpe <thorpej@wasabisystems.com> writes:

> On Sat, Jul 20, 2002 at 11:22:54AM +0930, Alan Modra wrote:
> 
>  > Check all object files involved in the link, including libraries and
>  > startup files, for a RW .rodata section.  I'm guessing you'll find one,
>  > indicating an assembler or more likely, source problem.
> 
> That's what I figured.  No .rodata* sections with the "W" bit set in
> any of:
> 
> 	crt0.o
> 	crtbegin.o
> 	append.o (the test program)
> 	libc.a (or libc.so)
> 	libm.a (or libm.so)
> 	libgcc.a
> 	libstdc++.a
> 	crtend.o
> 
> The problem occurs when the program is linked statically, as well, but
> the dynamic linker isn't invokved, so it doesn't croak.

The write bit is being set somewhere, and it almost certainly because
some writable input section is being mapped to the .rodata output
section.  Generate a map file using the -Map option, and look at all
the input sections to the .rodata output section.  Perhaps some input
section named other than .rodata* is being included in the output
section.

Ian

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

[Alan Modra]

On Fri, Jul 19, 2002 at 07:42:56PM -0700, Jason R Thorpe wrote:
> On Sat, Jul 20, 2002 at 11:22:54AM +0930, Alan Modra wrote:
> 
>  > Check all object files involved in the link, including libraries and
>  > startup files, for a RW .rodata section.  I'm guessing you'll find one,
>  > indicating an assembler or more likely, source problem.
> 
> That's what I figured.  No .rodata* sections with the "W" bit set in
> any of:

So it looks like an ld problem.  Run the link under gdb, with a
breakpoint on lang_process.  Step over each function called, inspecting
the output .rodata section at each step.  You'll find it in one of
output_bfd->sections, output_bfd->sections->next,
output_bfd->sections->next->next etc.  It might also be worth putting
a breakpoint on lang_add_section, and watching what happens to the
.rodata output section flags there.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[H. J. Lu]

On Thu, Jul 25, 2002 at 11:30:24PM -0500, Loren James Rittle wrote:
> (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
>  .gnu.linkonce.r._ZTISt12out_of_range
>                 0x08048fb0        0xc /var/tmp//ccAEn9wX.o
>                 0x08048fb0                _ZTISt12out_of_range
>  .gnu.linkonce.r._ZTSSt12out_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
> 

FWIW, on Linux/x86, I got

        .section        .gnu.linkonce.d._ZTISt12out_of_range,"aw",@progbits
        .section        .gnu.linkonce.r._ZTSSt12out_of_range,"a",@progbits
        .section        .gnu.linkonce.d._ZTISt11logic_error,"aw",@progbits
        .section        .gnu.linkonce.r._ZTSSt11logic_error,"a",@progbits
        .section        .gnu.linkonce.d._ZTISt9exception,"aw",@progbits
        .section        .gnu.linkonce.r._ZTSSt9exception,"a",@progbits

You may want to check out why BSDs are different.


H.J.

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

[Loren James Rittle]

(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
 .gnu.linkonce.r._ZTISt12out_of_range
                0x08048fb0        0xc /var/tmp//ccAEn9wX.o
                0x08048fb0                _ZTISt12out_of_range
 .gnu.linkonce.r._ZTSSt12out_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.

Regards,
Loren