From: Daniel Jacobowitz <dan@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>,
Pedro Alves <pedro@codesourcery.com>
Subject: [RFC/7.1] Reset breakpoints after load
Date: Sun, 14 Mar 2010 16:21:00 -0000 [thread overview]
Message-ID: <20100314162107.GG9310@caradoc.them.org> (raw)
Since this patch:
2009-06-17 Pierre Muller <muller@ics.u-strasbg.fr>
Pedro Alves <pedro@codesourcery.com>
* infcmd.c (post_create_inferior): Call breakpoint_re_set after target
is pushed for watchpoint promotion to hardware watchpoint.
GDB performs this sequence:
% gdb -quiet file
(gdb) break main
[Breakpoint set after prologue]
(gdb) target remote :PORT
[Connect to remote target]
[breakpoint_re_set called]
(gdb) load
(gdb) continue
If the prologue skipping logic reads from memory, then when
breakpoint_re_set is called, it will read garbage. Many of the
prologue analyzers do, although the effect is mitigated by
skip_prologue_using_sal, which is used in preference if possible.
I believe we worked around this bug locally for MIPS. I've also just
encountered it while testing a patch for ARM that changes the prologue
skipping behavior.
I can think of three solutions.
* Don't reset breakpoints here. Promote watchpoints and make no other
changes. A bit twisty to implement, unfortunately.
* Don't read from the target during prologue analyzers; only read from
the executable file. I like this solution best, and it has other
merits (it's faster!). But it's the most work.
* The easy solution: Reset breakpoints again once we know that target
memory is valid.
Any comments on this patch? It has no effect on test results on
arm-none-eabi today, and fixes two hundred or so failures with another
patch that required reading from the target during prologue analysis.
I'd like to do the long-term solution also, but it will take longer
than the 7.1 release.
--
Daniel Jacobowitz
CodeSourcery
2010-03-14 Daniel Jacobowitz <dan@codesourcery.com>
* symfile.c (generic_load): Reset breakpoints after loading.
---
gdb/symfile.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: gdb-mainline/gdb/symfile.c
===================================================================
--- gdb-mainline.orig/gdb/symfile.c 2010-03-11 00:23:57.000000000 -0800
+++ gdb-mainline/gdb/symfile.c 2010-03-14 08:45:43.000000000 -0700
@@ -1890,6 +1890,16 @@ generic_load (char *args, int from_tty)
for other targets too. */
regcache_write_pc (get_current_regcache (), entry);
+ /* Reset breakpoints. This should not be necessary, but it is
+ needed because of two other factors. One is that
+ post_create_inferior calls breakpoint_re_set, so breakpoints were
+ already reset when we connected to the target. The other is that
+ prologue analyzers read memory from the target, even though they
+ rely on the symbol table too. So when we reset breakpoints after
+ connection, we may have read uninitialized memory from the
+ target. */
+ breakpoint_re_set ();
+
/* FIXME: are we supposed to call symbol_file_add or not? According
to a comment from remote-mips.c (where a call to symbol_file_add
was commented out), making the call confuses GDB if more than one
next reply other threads:[~2010-03-14 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-14 16:21 Daniel Jacobowitz [this message]
2010-03-15 1:08 ` Joel Brobecker
2010-03-15 19:27 ` Pedro Alves
2010-03-17 0:04 ` Daniel Jacobowitz
2010-03-17 16:13 ` Pedro Alves
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=20100314162107.GG9310@caradoc.them.org \
--to=dan@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
/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