Re: [RFC/7.1] Reset breakpoints after load

[Daniel Jacobowitz <dan@codesourcery.com>]

On Mon, Mar 15, 2010 at 07:27:05PM +0000, Pedro Alves wrote:
> > * 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.
> 
> "only" would be too strong.  You'd want "prefer", like
> trust-readonly-sections.  We may have debug info available but
> no pure memory contents to read from.

Right.

> Given that I proposed exactly this at least a couple of times
> already,

I'd forgotten this, if I ever knew it :-)

> I'm not sure I agree in calling this a workaround though.

Your explanation is convincing.  I've rewritten the comment, and
checked it in.

> Wouldn't be such a stretch, although just
> 
>   - remove_breakpoints ();
> 
>    <do actual load>
> 
>   - breakpoint_re_set ();
> 
> would work too, and be simpler.

That seems like a good thing too... I'd support it, but I didn't
implement it today.

-- 
Daniel Jacobowitz
CodeSourcery

2010-03-16  Daniel Jacobowitz  <dan@codesourcery.com>

	* symfile.c (generic_load): Reset breakpoints after loading.

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.278
diff -u -p -r1.278 symfile.c
--- symfile.c	15 Mar 2010 09:31:34 -0000	1.278
+++ symfile.c	17 Mar 2010 00:03:09 -0000
@@ -1893,6 +1893,16 @@ generic_load (char *args, int from_tty)
      for other targets too.  */
   regcache_write_pc (get_current_regcache (), entry);
 
+  /* Reset breakpoints, now that we have changed the load image.  For
+     instance, breakpoints may have been set (or reset, by
+     post_create_inferior) while connected to the target but before we
+     loaded the program.  In that case, the prologue analyzer could
+     have read instructions from the target to find the right
+     breakpoint locations.  Loading has changed the contents of that
+     memory.  */
+
+  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