From 38963c97b7990d8a4f9cbe8b58ec0519e451e571 Mon Sep 17 00:00:00 2001 From: Daniel Jacobowitz Date: Wed, 17 Mar 2010 18:08:11 +0000 Subject: [PATCH] * symfile.c (generic_load): Reset breakpoints after loading. --- gdb/ChangeLog | 4 ++++ gdb/symfile.c | 10 ++++++++++ 2 files changed, 14 insertions(+) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 5578d4fab4..f1e5f6a0b3 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,7 @@ +2010-03-17 Daniel Jacobowitz + + * symfile.c (generic_load): Reset breakpoints after loading. + 2010-03-17 Tom Tromey * linux-nat.c (linux_nat_detach): Check debug_linux_nat. diff --git a/gdb/symfile.c b/gdb/symfile.c index 22c2852908..c1d64eaa5c 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -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 -- 2.34.1