From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D0D8B398E426; Thu, 28 Jan 2021 09:59:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0D8B398E426 From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/27205] [-m32] FAIL: gdb.base/longjmp.exp: next over longjmp(1) Date: Thu, 28 Jan 2021 09:59:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 09:59:46 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27205 --- Comment #6 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=3D2a7f6487d0a2= f9a5f16d0f67904ac35100313eb1 commit 2a7f6487d0a2f9a5f16d0f67904ac35100313eb1 Author: Tom de Vries Date: Thu Jan 28 10:59:42 2021 +0100 [gdb/breakpoints] Fix longjmp master breakpoint with separate debug info When running test-case gdb.base/longjmp.exp with target board unix/-m32= , we run into: ... (gdb) next^M Warning:^M Cannot insert breakpoint 0.^M Cannot access memory at address 0x7dbf7353^M ^M __libc_siglongjmp (env=3D0x804a040 , val=3D1) at longjmp.c:28^M 28 longjmps++;^M (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) ... The failure to access memory happens in i386_get_longjmp_target and is = due to glibc having pointer encryption (aka "pointer mangling" or "pointer gua= rd") of the long jump buffer. This is a known problem. In create_longjmp_master_breakpoint (which attempts to install a master longjmp breakpoint) a preference scheme is present, which installs a probe breakpoint if a libc:longjmp probe is present, and otherwise falls back to setting breakpoints at the names in the longjmp_names array. But in fact, both the probe breakpoint and the longjmp_names breakpoints are set. The latter ones are set when processing libc.so.debug, and the fo= rmer one when processing libc.so. In other words, this is the longjmp varia= nt of PR26881, which describes the same problem for master exception breakpoi= nts. This problem only triggers when the glibc debug info package is install= ed, which is not due to the debug info itself in libc.so.debug, but due to = the minimal symbols (because create_longjmp_master_breakpoint uses minimal symbols to translate the longjmp_names to addresses). The problem doesn't trigger for -m64, because there tdep->jb_pc_offset = is not set. Fix this similar to commit 1940319c0ef (the fix for PR26881): only inst= all longjmp_names breakpoints in libc.so/libc.so.debug if installing the libc:longjmp probe in libc.so failed. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-28 Tom de Vries PR breakpoints/27205 * breakpoint.c (create_longjmp_master_breakpoint_probe) (create_longjmp_master_breakpoint_names): New function, factored out of ... (create_longjmp_master_breakpoint): ... here. Only try to inst= all longjmp_names breakpoints in libc.so/libc.so.debug if installing probe breakpoint in libc.so failed. --=20 You are receiving this mail because: You are on the CC list for the bug.=