[Bug libstdc++/55041] prettyprinting/shared_ptr & cxx11 fails on some platforms

tromey at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Nov 16 20:47:00 GMT 2012


--- Comment #12 from Tom Tromey <tromey at gcc dot gnu.org> 2012-11-16 20:46:33 UTC ---
(In reply to comment #11)
> Tom, do you have any idea what's going on in comment 6 and comment 8 of this
> bug?

Not offhand.
If you send me the failing executable(s) I can take a look at their
debuginfo.  Maybe that will be useful.

I don't think gdb 7.3 really works with trunk after this patch, though:

commit 2dd133d84c8991217864523ea79d11f1885f1388
Author: mark <mark@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Mon Aug 20 20:27:46 2012 +0000

    dwarf2out.c: For DWARF 4+, output DW_AT_high_pc as constant offset.

This required a gdb change.

Another thing to try is turning on complaints before running the program
in gdb:

(gdb) set complaints 10000
(gdb) start

For me this prints tons of junk, some of which could actually be gcc

DW_AT_low_pc 0x0 is zero for DIE at 0xf055a [in module

debug_line address at offset 0x449b7 is 0 [in module

It's hard to say without debugging further, this is just a first glance.
I'm not sure if these could cause the problems you're seeing.

FWIW, the tests mostly work for me, except:

UNSUPPORTED: libstdc++-prettyprinters/shared_ptr.cc

In my case the issue seems to be weird debuginfo emitted by gcc;
look at what the breakpoint reports:

Breakpoint 1, _GLOBAL__sub_I__Z4makem () at

Setting it by hand with "gdb shared_ptr.exe" then "break 72":

(gdb) b 72
Breakpoint 1 at 0x400deb:
(3 locations)
(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y     0x0000000000400deb in main() 
1.2                         y     0x0000000000400ec0 in
1.3                         y     0x0000000000401070 in
std::_Sp_counted_deleter<int*, deleter, std::allocator<int>,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&) 

... very weird, looks like a gcc bug to me.

More information about the Gcc-bugs mailing list