* GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
@ 2002-07-18 20:07 Loren James Rittle
2002-07-19 3:47 ` Alan Modra
2002-07-19 11:16 ` Jason R Thorpe
0 siblings, 2 replies; 13+ messages in thread
From: Loren James Rittle @ 2002-07-18 20:07 UTC (permalink / raw)
To: binutils; +Cc: obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-18 20:07 GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13 Loren James Rittle
@ 2002-07-19 3:47 ` Alan Modra
2002-07-19 11:16 ` Jason R Thorpe
1 sibling, 0 replies; 13+ messages in thread
From: Alan Modra @ 2002-07-19 3:47 UTC (permalink / raw)
To: rittle; +Cc: binutils, obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-18 20:07 GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13 Loren James Rittle
2002-07-19 3:47 ` Alan Modra
@ 2002-07-19 11:16 ` Jason R Thorpe
2002-07-19 17:29 ` Alan Modra
1 sibling, 1 reply; 13+ messages in thread
From: Jason R Thorpe @ 2002-07-19 11:16 UTC (permalink / raw)
To: rittle; +Cc: binutils, obrien
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 11:16 ` Jason R Thorpe
@ 2002-07-19 17:29 ` Alan Modra
2002-07-19 18:21 ` Jason R Thorpe
0 siblings, 1 reply; 13+ messages in thread
From: Alan Modra @ 2002-07-19 17:29 UTC (permalink / raw)
To: Jason R Thorpe, rittle, binutils, obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 17:29 ` Alan Modra
@ 2002-07-19 18:21 ` Jason R Thorpe
2002-07-19 18:46 ` Alan Modra
0 siblings, 1 reply; 13+ messages in thread
From: Jason R Thorpe @ 2002-07-19 18:21 UTC (permalink / raw)
To: rittle, binutils, obrien
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 18:21 ` Jason R Thorpe
@ 2002-07-19 18:46 ` Alan Modra
2002-07-19 18:52 ` Jason R Thorpe
0 siblings, 1 reply; 13+ messages in thread
From: Alan Modra @ 2002-07-19 18:46 UTC (permalink / raw)
To: Jason R Thorpe, rittle, binutils, obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 18:46 ` Alan Modra
@ 2002-07-19 18:52 ` Jason R Thorpe
2002-07-19 19:43 ` Alan Modra
0 siblings, 1 reply; 13+ messages in thread
From: Jason R Thorpe @ 2002-07-19 18:52 UTC (permalink / raw)
To: rittle, binutils, obrien
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 18:52 ` Jason R Thorpe
@ 2002-07-19 19:43 ` Alan Modra
2002-07-19 21:14 ` Jason R Thorpe
0 siblings, 1 reply; 13+ messages in thread
From: Alan Modra @ 2002-07-19 19:43 UTC (permalink / raw)
To: Jason R Thorpe, rittle, binutils, obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 19:43 ` Alan Modra
@ 2002-07-19 21:14 ` Jason R Thorpe
2002-07-19 21:33 ` Ian Lance Taylor
2002-07-20 11:33 ` Alan Modra
0 siblings, 2 replies; 13+ messages in thread
From: Jason R Thorpe @ 2002-07-19 21:14 UTC (permalink / raw)
To: rittle, binutils, obrien
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 21:14 ` Jason R Thorpe
@ 2002-07-19 21:33 ` Ian Lance Taylor
2002-07-20 11:33 ` Alan Modra
1 sibling, 0 replies; 13+ messages in thread
From: Ian Lance Taylor @ 2002-07-19 21:33 UTC (permalink / raw)
To: Jason R Thorpe; +Cc: rittle, binutils, obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-19 21:14 ` Jason R Thorpe
2002-07-19 21:33 ` Ian Lance Taylor
@ 2002-07-20 11:33 ` Alan Modra
1 sibling, 0 replies; 13+ messages in thread
From: Alan Modra @ 2002-07-20 11:33 UTC (permalink / raw)
To: Jason R Thorpe, rittle, binutils, obrien
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
@ 2002-07-25 21:53 Loren James Rittle
2002-07-25 22:09 ` H. J. Lu
0 siblings, 1 reply; 13+ messages in thread
From: Loren James Rittle @ 2002-07-25 21:53 UTC (permalink / raw)
To: binutils; +Cc: gcc-bugs
(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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13
2002-07-25 21:53 Loren James Rittle
@ 2002-07-25 22:09 ` H. J. Lu
0 siblings, 0 replies; 13+ messages in thread
From: H. J. Lu @ 2002-07-25 22:09 UTC (permalink / raw)
To: rittle; +Cc: binutils, gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-07-26 4:53 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-18 20:07 GCC testsuite run before and after ~2.12.1 upgraded to pre-2.13 Loren James Rittle
2002-07-19 3:47 ` Alan Modra
2002-07-19 11:16 ` Jason R Thorpe
2002-07-19 17:29 ` Alan Modra
2002-07-19 18:21 ` Jason R Thorpe
2002-07-19 18:46 ` Alan Modra
2002-07-19 18:52 ` Jason R Thorpe
2002-07-19 19:43 ` Alan Modra
2002-07-19 21:14 ` Jason R Thorpe
2002-07-19 21:33 ` Ian Lance Taylor
2002-07-20 11:33 ` Alan Modra
2002-07-25 21:53 Loren James Rittle
2002-07-25 22:09 ` H. J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).