This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC/7.1] Reset breakpoints after load
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