From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E757D395BC5C; Wed, 16 Nov 2022 17:18:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E757D395BC5C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668619116; bh=pDCeltQOncQ06ZgKDd+5n06aQy4S4KXAsf0Kv560PRY=; h=From:To:Subject:Date:From; b=bc14XpTR3W+77jz+DGvUbch9uoevDs/WpyMQaeL9BzeBIcucQuy3PEMxL3h2fySU/ b+jqyQdTsT62lmvXJfyrHnJwlpzr6hj46W6ylk6R4FEErM3eTW6ptESyhIcdxZM/JV 1orW5FHj3D80kBlJ8oDtj1PH/H6njzKjXwpDCA/8= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tdep/29793] New: [gdb/tdep, powerpc] FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception without a handler. Date: Wed, 16 Nov 2022 17:18:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29793 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 inf 1 -10.1 y- 0x00007ffff7d79e60 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 =20=20=20=20=20=20=20=20=20 2.1 y 0x00007ffff7d79e74 2.2 y 0x00007ffff7ecdeec ... 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=