This is the mail archive of the 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] Entry point update with "run" command

Hi folks,

It seems GDB doesn't really update the entry point of an object file if
we "reload" the modified binary through the "run" command.

This can be clearly seen with the reread.exp testcase:

1 - Run reread until "foo" breakpoint
2 - Move reread2 on top of reread
3 - "Run" and expect GDB to notice that the binary has changed
4 - GDB says it will re-read the symbols
5 - The entry point of the second binary is just the same as the first
one. This causes problems with the displaced stepping since the entry
point is used to store the instructions.

The problem is that "init_entry_point_info" is never called with the
"run" command. If we do a "file", then we get the right entry point.

The attached patch does this on "reread_symbols", though it seems a
brute-force method. Is this OK?


Luis Machado

Index: hg/gdb/symfile.c
--- hg.orig/gdb/symfile.c	2008-04-24 08:09:30.000000000 -0700
+++ hg/gdb/symfile.c	2008-04-24 08:45:50.000000000 -0700
@@ -2467,6 +2467,7 @@
 	      objfile->mtime = new_modtime;
 	      reread_one = 1;
               reread_separate_symbols (objfile);
+	      init_entry_point_info (objfile);

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