This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC/7.1] Reset breakpoints after load


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]