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]

[RFA] Reset inferior_ptid after "kill"


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]