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] |
Hello, While working on the AIX debugger, I stumbled on the following problem. Using the reread testcase, I observed the following behavior: (gdb) shell cp reread1 reread (gdb) file reread Reading symbols from /[...]/reread...done. (gdb) b foo Breakpoint 1 at 0x10000420: file reread1.c, line 12. (gdb) run Starting program: /[...]/reread Breakpoint 1, foo () at reread1.c:12 12 x++; (gdb) kill Kill the program being debugged? (y or n) y (gdb) shell cp reread2 reread (gdb) shell touch reread (gdb) run `/[...]/reread' has changed; re-reading symbols. No registers. Breakpoint 1 at 0x100003e4: file reread2.c, line 7. The expected output is: `/[...]/reread' has changed; re-reading symbols. Breakpoint 1 at 0x100003e4: file reread2.c, line 7. Starting program: /home/brobecke/53-63/reread/reread Breakpoint 1, foo () at reread2.c:7 7 x++; The problem is that reinit_frame_caches does the following: reinit_frame_cache (void) { flush_cached_frames (); /* FIXME: The inferior_ptid test is wrong if there is a corefile. */ if (PIDGET (inferior_ptid) != 0) { select_frame (get_current_frame ()); } } As the comment hints, the inferior_ptid check is only approximate. In the case above, we end up having an inferior_ptid that's left from the previous run and is no longer applicable. At first, I thought that the check should be fixed, but then what would be the appropriate check. AFAIK, we still don't have a flag that says whether the inferior is running or not. Some use target_has_stack, others target_has_something_else, and here we use the inferior_ptid. On the other hand, I'm thinking that it seems pretty logical to reset the inferior_ptid after we've killed the inferior. We restore a state closer to the state we're in before we run the inferior for the first time. This is what this patch does. I'm just a touch uncertain about cross targets. Could that be harmful to such configurations. For the crosses I know of, I don't think so. 2005-12-19 Joel Brobecker <brobecker@adacore.com> * inflow.c (kill_command): Reset inferior_ptid after having killed the inferior. Tested on x86-linux. I would test it on AIX too, except that the testsuite no longer runs to completion (several testcases time out to death). It's on my list to fix it, but below other things... OK to commit? -- Joel
Attachment:
inflow.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |