'b ::new' causes gdb 8.1 to coredump ?

Jason Vas Dias jason.vas.dias@gmail.com
Sat Apr 21 22:52:00 GMT 2018

> start
> (gdb) b ::new
> cp-namespace.c:177: internal-error: block_symbol cp_lookup_bare_symbol(const language_defn*, const char*, const block*, domain_enum, int): Assertion `strstr (name, "::") == NULL' failed.
> A problem internal to GDB has been detected,

This occurs both when I built & linked the program with the 5.4.0 compiler ,
'-Wl,-rpath=${PATH_TO_5_4_0_LIBS},-rpath-link=${PATH_TO_5_4_0_LIBS}' ,
while GDB 8.1.11 is built with GCC 7.3.1 , and 
when built with GCC 7.3.1, with
'-Wl,-rpath=${PATH_TO_7_3_1_LIBS},-rpath-link=${PATH_TO_7_3_1_LIBS}' ,
(the two paths are quite different in my setup).

In both cases, GDB coredumps on 'b ::new' (after starting), and
fails to resolve any of:
  'b ::new(std::size_t)'
  'b operator ::new(std::size_t)'
  'b "operator::new(std::size_t)"
  'b extern "C++" "operator::new(::std::size_t)"
So how is one able to break on libstd++ C++ symbols in GDB ?
Especially 'operator ::new' -  I can break on any of
  { ::malloc, ::posix_memalign, ::memalign, ::sbrk .. }
but not any form of new() . Why ?

new is a proper symbol in libstdc++ :

$ nm -C /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.1/libstdc++.so.6.0.24 | grep 'new'
0000000000097680 T operator new(unsigned long)

Aha! It was the '::' namespace colons!

(gdb) b "operator new(std::size_t)"
Breakpoint 2 at 0x155554c30680: file ../../../../gcc-gcc-7-branch/libstdc++-v3/libsupc++/new_op.cc, line 43.
(gdb) q

But I don't think the presence or absence of leading global namespace
'::' colons should cause GDB to coredump or fail to resolve operator
new() .

Doesn't GDB understand C++ namespaces ?

Thanks, Jason

More information about the Gdb mailing list