From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BDC883858C60; Sun, 31 Dec 2023 01:46:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BDC883858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703987178; bh=TqPp33C7Z4W7d1Amvwk2HbyEbQlGQkZeV2d0pvMd0IQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jUagOOPk2gKCfVtddtH3/lylbJ42gyqtsDD9RQztPTtfAxtmt9UuyxEmWzgpLpVFX WlhyaTvK3M1vGE0Kltkf6zU7YLNQE+TO8Y4LMHW8cLsalCb9O6myb/reKxnrhl6lgm CFYAcN/tm9/BAmbbMvsBRzn+e/Wb3XJ62wWErkfU= From: "peter0x44 at disroot dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/31194] Stepping on "int3" instruction fails assertion. Date: Sun, 31 Dec 2023 01:46:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: peter0x44 at disroot dot 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=3D31194 --- Comment #7 from Peter0x44 --- > I'm not really sure how int3 is supposed to be handled Perhaps it would be beneficial to state what my preferences would be. On Windows it is common to use it as a "continuable assertion", the Microso= ft compiler has the intrinsic __debugbreak() to generate it, along with clang __builtin_debugtrap(). I expect it to break pointing to the line containing= the assertion, if defined in a macro likeso: #define assert(e) do { if (!e) __asm__("int3") } while (0) After which "continue" or "step" would behave "as expected" Maybe there's some cases I haven't considered where this could be problemat= ic, or the issue actually lies with the gcc/clang generated debug info. To be clear, the assertion fails in the same way even if you build the executable using the clang __builtin_debugtrap() intrinsic. There is a workaround for my case - you can use __builtin_trap, which compi= les to "ud2", and then use `j +1` to skip the ud2 when debugging. However, gcc treats code following __builtin_trap() as dead, so it's not always possible= to step past the assertion. Related info that made me think about assert macros more generally: https://nullprogram.com/blog/2022/06/26/ Some of this is off topic but I figure more info can't hurt. --=20 You are receiving this mail because: You are on the CC list for the bug.=