From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 738963858417; Sat, 31 Dec 2022 07:51:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 738963858417 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1672473106; bh=1HQ7UQxZ4ydmaXp3eLzdCFmBtfqW9B6/be5gtzG626A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Epp28eBjoVge6VdleR8E9aYdTAbKBEqgdLnpJ1XnwfMPFpbch4erWusbi0fBfpmBC dvumFIeUrPXAgpvHA8kKcoJZdRILsJQZqUXWdbph2VqVI+jSH3gYnWy/LdS2bYCrFy kPZQHB9qn+JdrcBtuiVbpFoYgLiD57DhM+DJEmn4= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug python/27247] FAIL: gdb.python/py-finish-breakpoint2.exp: check FinishBreakpoint in catch() Date: Sat, 31 Dec 2022 07:51:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: python X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit 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: Message-ID: In-Reply-To: References: 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=3D27247 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D64760036a846= 099158bb2bab5370ae033dde8db0 commit 64760036a846099158bb2bab5370ae033dde8db0 Author: Tom de Vries Date: Sat Dec 31 08:51:40 2022 +0100 [gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32 [ Partial resubmission of an earlier submission by Andrew ( https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html= ), so listing him as co-author. ] With x86_64-linux and target board unix/-m32, we have: ... (gdb) continue^M Continuing.^M Exception #10^M ^M Breakpoint 3, throw_exception_1 (e=3D10) at py-finish-breakpoint2.cc:23= ^M 23 throw new int (e);^M (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \ check FinishBreakpoint in catch() ... The following scenario happens: - set breakpoint in throw_exception_1, a function that throws an except= ion - continue - hit breakpoint, with call stack main.c:38 -> throw_exception_1 - set a finish breakpoint - continue - hit the breakpoint again, with call stack main.c:48 -> throw_exception -> throw_exception_1 Due to the exception, the function call did not properly terminate, and= the finish breakpoint didn't trigger. This is expected behaviour. However, the intention is that gdb detects this situation at the next s= top and calls the out_of_scope callback, which would result here in this test-case in a rather confusing "exception did not finish" message. So the probl= em is that this message doesn't show up, in other words, the out_of_scope callback is not called. [ Note that the fact that the situation is detected only at the next st= op (wherever that happens to be) could be improved upon, and the earlier submission did that by setting a longjmp breakpoint. But I'm consideri= ng this problem out-of-scope for this patch. ] Note that the message does show up later, at thread exit: ... [Inferior 1 (process 20046) exited with code 0236]^M exception did not finish ...^M ... The decision on whether to call the out_of_scope call back is taken in bpfinishpy_detect_out_scope_cb, and the interesting bit is here: ... if (b->pspace =3D=3D current_inferior ()->pspace && (!target_has_registers () || frame_find_by_id (b->frame_id) =3D=3D NULL)) bpfinishpy_out_of_scope (finish_bp); ... In the case of the thread exit, the callback triggers because target_has_registers () =3D=3D 0. So why doesn't the callback trigger in the case of the breakpoint? Well, the b->frame_id is the frame_id of the frame of main (the frame in which the finish breakpoint is supposed to trigger), so AFAIU frame_find_by_id (b->frame_id) =3D=3D NULL will only be true once we've left main, at which point I guess we don't stop till thread exit. Fix this by saving the frame in which the finish breakpoint was created, and using frame_find_by_id () =3D=3D NULL on that frame instead, such that = we have: ... (gdb) continue^M Continuing.^M Exception #10^M ^M Breakpoint 3, throw_exception_1 (e=3D10) at py-finish-breakpoint2.cc:23= ^M 23 throw new int (e);^M exception did not finish ...^M (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \ check FinishBreakpoint in catch() ... Still, the test-case is failing because it's setup to match the behavio= ur that we get on x86_64-linux with target board unix/-m64: ... (gdb) continue^M Continuing.^M Exception #10^M stopped at ExceptionFinishBreakpoint^M (gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \ check FinishBreakpoint in catch() ... So what happens here? Again, due to the exception, the function call d= id not properly terminate, but the finish breakpoint still triggers. This is somewhat unexpected. This happens because it just so happens to be that the fra= me return address at which the breakpoint is set, is also the first instruction after the exception has been handled. This is a know problem, filed as PR29909, so KFAIL it, and modify the test-case to expect the out_of_sco= pe callback. Also add a breakpoint after setting the finish breakpoint but before throwing the exception, to check that we don't call the out_of_scope callback too early. Tested on x86_64-linux, with target boards unix/-m32. Co-Authored-By: Andrew Burgess PR python/27247 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D27247 --=20 You are receiving this mail because: You are on the CC list for the bug.=