|
If you debug current GDB, set a "catch catch/throw/rethrow"
catchpoint, and then do "info breakpoints", the top GDB hits an
internal error:
(top-gdb) catch catch
Catchpoint 1 (catch)
(top-gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y src/gdb/breakpoint.c:6040: internal-error: void print_one_breakpoint_location(breakpoint*, bp_location*, int, bp_location**, int): Assertion `b->loc == NULL || b->loc->next == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The assertion in question is asserting that a breakpoint with a
print_one method only has one location, and it fails because this
catchpoint ends up with two locations.
Internally, "catch catch" sets a breakpoint at __cxa_begin_catch. If
we do that manually, we see the locations:
(top-gdb) b -qualified __cxa_begin_catch
Breakpoint 2 at 0xb122b0 (2 locations)
(top-gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
2.1 y 0x0000000000b122b0 <__cxa_begin_catch>
2.2 y 0x00007ffff2f4ddb0 in __cxxabiv1::__cxa_begin_catch(void*) at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:41
Note that I had used -qualified. It seems strange that we get a
location for a namespaced symbol, but that happens because the minimal
symbol for that address is indeed called __cxa_begin_catch.
The real issue is that gdb is linked with
-static-libgcc/-static-libstdc++. And then, it _also_ ends up with
shared libstc++ loaded:
(top-gdb) info sharedlibrary stdc++
From To Syms Read Shared Object Library
0x00007ffff2f4b380 0x00007ffff2ffc018 Yes /lib64/libstdc++.so.6
Location 2.2 is set within libstdc++.so.6's range:
(top-gdb) p 0x00007ffff2f4b380 <= 0x00007ffff2f4ddb0 && 0x00007ffff2f4ddb0 < 0x00007ffff2ffc018
$1 = true
So due to -static-lib*, we end up with _two_ copies of the
__cxa_begin_catch code:
(top-gdb) disassemble 0x0000000000b122b0
Dump of assembler code for function __cxa_begin_catch:
0x0000000000b122b0 <+0>: push %rbx
0x0000000000b122b1 <+1>: mov %rdi,%rbx
0x0000000000b122b4 <+4>: callq 0xb11a80 <__cxa_get_globals>
0x0000000000b122b9 <+9>: movabs $0xb8b1aabcbcd4d500,%rdx
...
(top-gdb) disassemble 0x00007ffff2f4ddb0
Dump of assembler code for function __cxxabiv1::__cxa_begin_catch(void*):
0x00007ffff2f4ddb0 <+0>: push %rbx
0x00007ffff2f4ddb1 <+1>: mov %rdi,%rbx
0x00007ffff2f4ddb4 <+4>: callq 0x7ffff2f4a090 <__cxa_get_globals@plt>
0x00007ffff2f4ddb9 <+9>: movabs $0xb8b1aabcbcd4d500,%rdx
...
I think we end up with libstdc++.so.6 loaded because
libsource-highlight.so depends on it.
Irrespective of whether it's a good idea to use
-static-libgcc/-static-libstdc++, GDB should not crash. Since there
are two copies of the code, it seems right to have more than one
location. So the fix is just to remove the assertion.
A testcase is included, which mimics the scenerio described above,
with binary linked with -static-lib{stdc++,gcc} and a shared library
that is linked normally, along with other combinations for good
measure.
gdb/ChangeLog:
2019-07-09 Pedro Alves <palves@redhat.com>
PR c++/15468
* breakpoint.c (print_one_breakpoint_location): Remove
single-location assert.
gdb/testsuite/ChangeLog:
2019-07-09 Pedro Alves <palves@redhat.com>
PR c++/15468
* gdb.cp/except-multi-location-lib.cc: New.
* gdb.cp/except-multi-location-main.cc: New.
* gdb.cp/except-multi-location.exp: New.
|
