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

[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]

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.

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cel at us dot ibm.com,
                   |                            |ulrich.weigand at de dot ibm.com

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

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

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
That behaviour is due to create_std_terminate_master_breakpoint:
...
          addr = bp_objfile_data->terminate_msym.value_address ();
          b = create_internal_breakpoint (objfile->arch (), addr,
                                          bp_std_terminate_master);
...
which gets the minimal symbol for std::terminate, and then set a breakpoint
on its address, in other words, it does break *std::terminate.

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

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

[cel at us dot ibm.com]

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

--- Comment #2 from Carl E Love <cel at us dot ibm.com> ---
Tom:

On Wed, 2022-11-16 at 17:22 +0000, vries at gcc dot gnu.org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=29793 
> 
> --- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
> That behaviour is due to create_std_terminate_master_breakpoint:
> ...
>           addr = bp_objfile_data->terminate_msym.value_address ();
>           b = create_internal_breakpoint (objfile->arch (), addr,
>                                           bp_std_terminate_master);
> ...
> which gets the minimal symbol for std::terminate, and then set a
> breakpoint
> on its address, in other words, it does break *std::terminate.
> 

Yes, this is on my list of gdb failures that I am looking at.  I have
only been able to spend a little time looking at it before getting
distracted.  It looks like you have identified the issue a bit more
than I have so far. 

I have been trying to work my way thru the list of GDB failures on
PowerPC for the last year+.  We have made good progress reducing the
number of failures on PowerPC.  I am trying to finish up a patch for 
gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp then
I hope to get back to this bug and the issue with gdb.base/store.exp.

Thanks for the bugzilla.

                          Carl

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

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

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
This fixes the test-case:
...
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 490708938ec..95a141d2933 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -3574,6 +3574,8 @@ create_std_terminate_master_breakpoint (void)
            }

          addr = bp_objfile_data->terminate_msym.value_address ();
+         addr = gdbarch_skip_prologue_noexcept (objfile->arch (), addr);
+         
          b = create_internal_breakpoint (objfile->arch (), addr,
                                          bp_std_terminate_master);
          b->locspec = new_explicit_location_spec_function (func_name);
...
and gets us a master breakpoint at:
...
-10     std::terminate master keep n   0x00007ffff7d79e74 <std::terminate()+20>
inf 1
-10.1                              y-  0x00007ffff7d79e74 <std::terminate()+20>
inf 1
...

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

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

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Carl E Love from comment #2)
> I have been trying to work my way thru the list of GDB failures on
> PowerPC for the last year+.

Yes, I noticed, much appreciated :)

> We have made good progress reducing the
> number of failures on PowerPC.

Agreed.  If I run the testsuite and grep -v the gdb.reverse fails, there are
not a lot of fails left.

> I am trying to finish up a patch for 
> gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp then

OK, good to know.

> I hope to get back to this bug and the issue with gdb.base/store.exp.

Ack.  I don't see the gdb.base/store.exp one though, could you file a PR for
that?

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

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

[cel at us dot ibm.com]

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

--- Comment #5 from Carl E Love <cel at us dot ibm.com> ---
I applied the fix in comment 3 to the current gdb source tree and tested it on
a Power 10 system.  The change fixes the two test failures for test
gdb.cp/gdb2495.exp and does not introduce any additional failures.

Tom, are you planning on posting the fix?

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

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

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Carl E Love from comment #5)
> I applied the fix in comment 3 to the current gdb source tree and tested it
> on a Power 10 system.  The change fixes the two test failures for test
> gdb.cp/gdb2495.exp and does not introduce any additional failures.
> 
> Tom, are you planning on posting the fix?

Thanks for testing.

I've also tested on x86_64-linux, no regressions.

I was not happy with the fix, and dug a little further, till I got to:
...
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 490708938ec..09a90843c8b 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -3574,6 +3574,9 @@ create_std_terminate_master_breakpoint (void)
            }

          addr = bp_objfile_data->terminate_msym.value_address ();
+         if (gdbarch_skip_entrypoint_p (objfile->arch ()))
+           addr = gdbarch_skip_entrypoint (objfile->arch (), addr);
+
          b = create_internal_breakpoint (objfile->arch (), addr,
                                          bp_std_terminate_master);
          b->locspec = new_explicit_location_spec_function (func_name);
...
which gives us:
...
-10     std::terminate master keep n   0x00007ffff7d79e68 <std::terminate()+8>
inf 1
-10.1                              y-  0x00007ffff7d79e68 <std::terminate()+8>
inf 1
...

The description of the gdbarch function matches pretty well the situation we've
analyzed:
...
/* On some platforms, a single function may provide multiple entry points,      
   e.g. one that is used for function-pointer calls and a different one         
   that is used for direct function calls.                                      
   In order to ensure that breakpoints set on the function will trigger         
   no matter via which entry point the function is entered, a platform          
   may provide the skip_entrypoint callback.  It is called with IP set          
   to the main entry point of a function (as determined by the symbol table),   
   and should return the address of the innermost entry point, where the        
   actual breakpoint needs to be set.  Note that skip_entrypoint is used        
   by GDB common code even when debugging optimized code, where skip_prologue   
   is not used. */

extern bool gdbarch_skip_entrypoint_p (struct gdbarch *gdbarch);
...

I'm happy to submit this one.

The only question I have left is if there are other cases where we need to do
this.

BTW I noticed:
...
...

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

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

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
> BTW I noticed:
> ...

  addr = bp_objfile_data->exception_msym.value_address ();
  addr = gdbarch_convert_from_func_ptr_addr
    (gdbarch, addr, current_inferior ()->top_target ());
  b = create_internal_breakpoint (gdbarch, addr, bp_exception_master);

> ...

here some similar treatment in create_exception_master_breakpoint_hook, but
that one it not used, instead the probe interface is used.

Perhaps I'll find a configuration where probes are not used and I can see the
effect of making changes here.  Or, I could disable the probe interface only
for the master exception breakpoint, and try that.

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

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

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand <uweigand at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ulrich.weigand at de dot ibm.com   |uweigand at gcc dot gnu.org

--- Comment #8 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
This is all quite a mess, it would appear.  There's many callers of
create_internal_breakpoint that want to set a breakpoint at the start of a
function that is looked up via name as an msymbol.  These really should all do
the same thing, but right now there's many different variants.

I believe the most general sequence that should work on all targets would be to
use, in this order:

- gdbarch_convert_from_func_ptr_addr
  (convert from a function descriptor address to a text address)

- gdbarch_addr_bits_remove
  (remove ISA marker bits in the address)

- gdbarch_deprecated_function_start_offset
  (only used on VAX - seems redundant with either convert_from_func_ptr_addr or
skip_entrypoint, and should probably be removed)

- gdbarch_skip_entrypoint
  (select the entrypoint to set a breakpoint on)

I think it would be good to use some appropriate abstraction that makes sure
these steps are followed in all those cases where we want to set an internal
breakpoint on a function by name, but I'm not sure what this is exactly.

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

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

[cel at us dot ibm.com]

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

--- Comment #9 from Carl E Love <cel at us dot ibm.com> ---
I tested the change in comment 6 on Power 10.  It worked fine.

I have not had time to dig into Ulrich's comments in comment 8 yet.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #8)
> - gdbarch_deprecated_function_start_offset
>   (only used on VAX - seems redundant with either convert_from_func_ptr_addr
> or skip_entrypoint, and should probably be removed)

Filed PR29804 - "[gdb/tdep, vax] Remove
gdbarch_deprecated_function_start_offset".

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

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

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #7)
> Or, I could disable the probe interface
> only for the master exception breakpoint, and try that.

FTR, I disabled the probe interface in the code and added the
gdbarch_skip_entrypoint call, but observed no difference, I guess because
_Unwind_DebugHook is a static function and only has a local entry point.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #8)
> - gdbarch_addr_bits_remove
>   (remove ISA marker bits in the address)

I think we can skip this because this is about addresses at runtime, and we're
getting the addresses from the minimal symbol table.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14461
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14461&action=edit
Tentative untested patch

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

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

[vries at gcc dot gnu.org]

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

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #13)
> Created attachment 14461 [details]
> Tentative untested patch

Submitted:
https://sourceware.org/pipermail/gdb-patches/2022-November/193982.html

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

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

[cel at us dot ibm.com]

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

--- Comment #15 from Carl E Love <cel at us dot ibm.com> ---
I tried to apply the patch to the very latest GDB tree.  It doesn't apply. 
Just wanted to see if I could help test the proposed patch.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Carl E Love from comment #15)
> I tried to apply the patch to the very latest GDB tree.  It doesn't apply. 
> Just wanted to see if I could help test the proposed patch.

Hi Carl, that would be great.

I've clicked on the link, then on "Raw Unified" which got me here (
https://sourceware.org/bugzilla/attachment.cgi?id=14461&action=diff&collapsed=&headers=1&format=raw
).

Then I saved as text file, which got me attachment.txt.

Then I applied onto recent commit 5e219e0f460 ("gdbserver/linux-x86: move lwp
declaration out of __x86_64__ region"):
...
$ patch -p1 < attachment.txt 
patching file gdb/breakpoint.c
$ 
...

So, that works for me.

Then I tried "View", which got me here (
https://sourceware.org/bugzilla/attachment.cgi?id=14461 ).

I saved as text file to
0001-gdb-tdep-Fix-gdb.cp-gdb2495.exp-on-powerpc64le.txt.

Then I applied onto the same commit:
...
$ git am 0001-gdb-tdep-Fix-gdb.cp-gdb2495.exp-on-powerpc64le.txt
Applying: Fix gdb.cp/gdb2495.exp on powerpc64le
$ 
...

So, unfortunately I'm not able to reproduce your problem in applying.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #17 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Carl E Love from comment #15)
> I tried to apply the patch to the very latest GDB tree.  It doesn't apply. 
> Just wanted to see if I could help test the proposed patch.

Btw, picking it from the mailing list is also possible:
...
$ git log
commit 15253318be0995200cc59929ca32eedbfd041e45 (HEAD -> master
, origin/master, origin/HEAD)
Author: Tsukasa OI <research_trasio@irq.a4lg.com>
Date:   Mon Oct 24 10:08:15 2022 +0000

    RISC-V: Add 'Ssstateen' extension and its CSRs
$ git-pw patch list
  ...
| 60847 | 18 hours ago   | Fix gdb.cp/gdb2495.exp on powerpc64le                
      | Tom de Vries (tdevries@suse.de)                   | new     | no       
 |            
|
  ...
$ git-pw patch apply 60847
$ git log
commit 317d28220514dd9b53530f6199f2b171c918db9e (HEAD -> master
)
Author: Tom de Vries <tdevries@loganberry-1.arch.suse.de>
Date:   Fri Nov 18 17:43:23 2022 +0100

    Fix gdb.cp/gdb2495.exp on powerpc64le
...

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

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

[cel at us dot ibm.com]

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

--- Comment #18 from Carl E Love <cel at us dot ibm.com> ---
The issue on Friday was one of the hunks would not apply.  I could see the
source code was clearly different.  Even after doing a fresh pull it didn't
apply.  

I update the tree again this morning and applied the patch:

carll@ltcd97-lp3:~/GDB/binutils-gdb-test$ patch -p 1 < ../tom.patch
patching file gdb/breakpoint.c
Hunk #1 succeeded at 3296 (offset 13 lines).
Hunk #2 succeeded at 3310 (offset 13 lines).
Hunk #3 succeeded at 3586 (offset 13 lines).
Hunk #4 succeeded at 3613 (offset 13 lines).
Hunk #5 succeeded at 3683 (offset 13 lines).
Hunk #6 succeeded at 3705 (offset 13 lines).

So upstream seems to have moved a little but not a problem.  The source code
conflict is gone.

I ran the test before doing the make and the make install. The test fails as
expected:

   make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb  gdb.cp/gdb2495.exp    '

  WARNING: Couldn't find the global config file.
  WARNING: Couldn't find tool init file
  WARNING: Couldn't find the global config file.
  WARNING: Couldn't find tool init file
  WARNING: Couldn't find the global config file.
  WARNING: Couldn't find tool init file
  WARNING: Couldn't find the global config file.
  WARNING: No tool specified
  WARNING: Couldn't find the global config file.
  make[4]: *** [Makefile:226: do-check-single] Error 1
  make[3]: *** [Makefile:161: check] Error 2
  make[2]: *** [Makefile:1922: check] Error 2
  make[1]: *** [Makefile:13585: check-gdb] Error 2

I checked the log file and see the failure:
-----------------------

(gdb) run 
Starting program:
/home/carll/GDB/build-twst/gdb/testsuite/outputs/gdb.cp/gdb2495/gdb2495 ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M

Breakpoint 1, main () at
/home/carll/GDB/build-test/gdb/testsuite/../../../binutils-gdb-test/gdb/testsuite/gdb.c\
p/gdb2495.cc:75^M
75        exceptions.raise_signal (-1);^M
(gdb) p exceptions.no_throw_function()^M
$1 = 1^M
(gdb) PASS: gdb.cp/gdb2495.exp: p exceptions.no_throw_function()
p exceptions.throw_function_with_handler()^M
Handled^M
$2 = 2^M
(gdb) PASS: gdb.cp/gdb2495.exp: p exceptions.throw_function_with_handler()
p exceptions.throw_function()^M
terminate called after throwing an instance of 'int'^M
^M
Program received signal SIGABRT, Aborted.^M
0x00007ffff76b9a8c in __pthread_kill_implementation () 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.
bt^M
#0  0x00007ffff76b9a8c in __pthread_kill_implementation () from
/lib64/libc.so.6^M
#1  0x00007ffff7657a9c in raise () from /lib64/libc.so.6^M
#2  0x00007ffff7630948 in abort () from /lib64/libc.so.6^M
#3  0x00007ffff7b19fa8 in __gnu_cxx::__verbose_terminate_handler() () from
/lib64/libstdc++.so.6^M
#4  0x00007ffff7b15114 in __cxxabiv1::__terminate(void (*)()) () from
/lib64/libstdc++.so.6^M
#5  0x00007ffff7b151e0 in std::terminate() () from /lib64/libstdc++.so.6^M
#6  0x00007ffff7b156a4 in __cxa_throw () from /lib64/libstdc++.so.6^M
#7  0x0000000010000f30 in SimpleException::throw_function (this=0x10020082
<exceptions>) at /home/carll/GDB/buil\
d-test/gdb/testsuite/../../../binutils-gdb-test/gdb/testsuite/gdb.cp/gdb2495.cc:41^M
#8  <function called from gdb>^M
#9  main () at
/home/carll/GDB/build-test/gdb/testsuite/../../../binutils-gdb-test/gdb/testsuite/gdb.cp/gdb2495.\
cc:75^M
(gdb) FAIL: gdb.cp/gdb2495.exp: bt after returning from a popped frame
info breakpoints^M
Num     Type           Disp Enb Address            What^M
1       breakpoint     keep y   0x0000000010000ca8 in main() at
/home/carll/GDB/build-test/gdb/testsuite/../../.\
./binutils-gdb-test/gdb/testsuite/gdb.cp/gdb2495.cc:75^M
        breakpoint already hit 1 time^M
(gdb) PASS: gdb.cp/gdb2495.exp: info breakpoints
set unwind-on-terminating-exception off^M
(gdb) PASS: gdb.cp/gdb2495.exp: set unwind-on-terminating-exception off
show unwind-on-terminating-exception^M
Unwind stack if a C++ exception is unhandled while in a call dummy is off.^M
(gdb) PASS: gdb.cp/gdb2495.exp: turn off unwind on terminating exception flag
p exceptions.throw_function()^M
terminate called recursively^M
^M
Program received signal SIGABRT, Aborted.^M
0x00007ffff76b9a8c in __pthread_kill_implementation () 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) PASS: gdb.cp/gdb2495.exp: call a function that raises an exception with
unwinding off..
delete breakpoints^M
Delete all breakpoints? (y or n) y^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M

---------------------------

After doing the make and make install the test passes, the results from the
gdb/testsuite/gdb.lot file:

--------------------------
                === gdb Summary ===

# of expected passes            14

The patch is working on Power 10.

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

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=829b6b3736d972f5fbacda09c82b31802d3b594c

commit 829b6b3736d972f5fbacda09c82b31802d3b594c
Author: Tom de Vries <tdevries@loganberry-1.arch.suse.de>
Date:   Wed Nov 23 06:52:42 2022 +0100

    Fix gdb.cp/gdb2495.exp on powerpc64le

    On powerpc64le-linux I ran into this FAIL:
    ...
    (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.
    ...

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

    We can fix this by simply adding the missing gdbarch_skip_entrypoint call
in
    create_std_terminate_master_breakpoint, but we try to do this a bit more
    generic, by:
    - adding a variant of function create_internal_breakpoint which takes a
      minimal symbol instead of an address as argument
    - in the new function:
      - using both gdbarch_convert_from_func_ptr_addr and
gdbarch_skip_entrypoint
      - documenting why we don't need to use gdbarch_addr_bits_remove
      - adding a note about possibly
        needing gdbarch_deprecated_function_start_offset.
    - using the new function in:
      - create_std_terminate_master_breakpoint
      - create_exception_master_breakpoint_hook, which currently uses only
        gdbarch_convert_from_func_ptr_addr.

    Note: we could use the new function in more locations in breakpoint.c, but
    as we're not aware of any related failures, we declare this out of scope
for
    this patch.

    Tested on x86_64-linux, powerpc64le-linux.

    Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
    Tested-by: Carl Love <cel@us.ibm.com>
    PR tdep/29793
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29793

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

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |13.1

--- Comment #20 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed by aforementioned commit.

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