From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/tdep] Use cached breakpoint kind in breakpoint_kind
Date: Fri, 7 Jun 2024 16:38:21 +0200 [thread overview]
Message-ID: <20240607143821.29797-1-tdevries@suse.de> (raw)
With test-case gdb.base/solib-probes-nosharedlibrary.exp on arm-linux, I get:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
0xf7fd267a in ?? ()^M
(gdb) FAIL: $exp: continue to breakpoint: main
...
This happens as follows:
- the starti command is called,
- gdb loads symbols for ld.so,
- the "shlib events" breakpoint is inserted at the address of _dl_debug_state,
- execution stops at ld.so _start, and the inserted breakpoint is removed,
- the nosharedlibrary command is called,
- gdb forgets about all shared library symbols,
- the continue command is called,
- gdb re-inserts the "shlib events" breakpoint, but the call to
breakpoint_kind returns the wrong value: ARM_BP_KIND_ARM instead of
ARM_BP_KIND_THUMB, so the wrong type of breakpoint is inserted, and
- when execution hits the breakpoint, the SIGILL triggers.
In order to correctly set a breakpoint on an address for arm, gdb needs to
known whether that address is in thumb or arm code, and the problem is that
that information is no longer available due to the nosharedlibrary command.
However, the breakpoint kind is is available from the previous time the
breakpoint was inserted.
Fix this in breakpoint_kind, by using the info cached in bl->target_info.kind,
if available.
Tested on arm-linux.
PR tdep/31817
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31817
---
gdb/breakpoint.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index a973518ac5f..0c99ccc9568 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -2792,7 +2792,11 @@ breakpoint_kind (const struct bp_location *bl, CORE_ADDR *addr)
regcache, addr);
}
else
- return gdbarch_breakpoint_kind_from_pc (bl->gdbarch, addr);
+ {
+ if (bl->target_info.kind != 0)
+ return bl->target_info.kind;
+ return gdbarch_breakpoint_kind_from_pc (bl->gdbarch, addr);
+ }
}
/* Rethrow the currently handled exception, if it's a TARGET_CLOSE_ERROR.
base-commit: 3a659c2a30f40c2a734fda5566098804b5ee38fc
--
2.35.3
next reply other threads:[~2024-06-07 14:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 14:38 Tom de Vries [this message]
2024-07-31 11:26 ` [PING][PATCH] " Tom de Vries
2024-08-05 16:00 ` Tom de Vries
2024-08-05 17:08 ` Simon Marchi
2024-08-06 7:17 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240607143821.29797-1-tdevries@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox