[Bug tdep/29793] New: [gdb/tdep, powerpc] FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception without a handler.

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29793

            Bug ID: 29793
           Summary: [gdb/tdep, powerpc] FAIL: gdb.cp/gdb2495.exp: call a
                    function that raises an exception without a handler.
           Product: gdb
           Version: 12.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With powerpc64le I ran into this failure:
...
(gdb) p exceptions.throw_function()^M
terminate called after throwing an instance of 'int'^M
^M
Program received signal SIGABRT, Aborted.^M
0x00007ffff7979838 in raise () from /lib64/libc.so.6^M
The program being debugged was signaled while in a function called from GDB.^M
GDB remains in the frame where the signal was received.^M
To change this behavior use "set unwindonsignal on".^M
Evaluation of the expression containing the function^M
(SimpleException::throw_function()) will be abandoned.^M
When the function is done executing, GDB will silently stop.^M
(gdb) FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception
without a handler.
...

For contrast, with x86_64 instead I have:
...
(gdb) PASS: gdb.cp/gdb2495.exp: p exceptions.throw_function_with_handler()
p exceptions.throw_function()^M
The program being debugged entered a std::terminate call, most likely^M
caused by an unhandled C++ exception.  GDB blocked this call in order^M
to prevent the program from being terminated, and has restored the^M
context to its original state before the call.^M
To change this behaviour use "set unwind-on-terminating-exception off".^M
Evaluation of the expression containing the function
(SimpleException::throw_function())^M
will be abandoned.^M
(gdb) PASS: gdb.cp/gdb2495.exp: call a function that raises an exception
without a handler.
...

So, the problem seems to be that doing an inferior call sets a breakpoint on
std::terminate that is not triggered, and instead we run into the actual
std::terminate.

Using maint info break, we can see the internal breakpoints, where we have:
...
-10     std::terminate master keep n   0x00007ffff7d79e60 <std::terminate()>
inf 1
-10.1                              y-  0x00007ffff7d79e60 <std::terminate()>
inf 1
...

In contrast, if we set a user breakpoint on std::terminate, we have instead:
...
(gdb) b std::terminate
Breakpoint 2 at 0x7ffff7d79e74 (2 locations)
(gdb) info breakpoint
Num     Type           Disp Enb Address            What
2       breakpoint     keep y   <MULTIPLE>         
2.1                         y   0x00007ffff7d79e74 <std::terminate()+20>
2.2                         y   0x00007ffff7ecdeec <std::terminate()@plt>
...

So, AFAIU, the following happens:
- we start an inferior call
- an internal std::terminate breakpoint is set on the global entry point
- the inferior call uses the local entry point
- the breakpoint is not triggered
- we run into std::terminate

-- 
You are receiving this mail because:
You are on the CC list for the bug.