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]

Re: [RFA] Reset inferior_ptid after "kill"


On Mon, Dec 19, 2005 at 10:41:22PM +0400, Joel Brobecker wrote:
> Hello,
> 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.

There's a certain amount of indecision between the various target_has_*
flags, but they are clearly appropriate here.  Take a look at
deprecated_safe_get_selected_frame.  I'm tempted to rename it to
something more logical, and use it here.

> 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 makes sense, but in that case I don't think kill_command is a
useful place to put this - what if the target exits normally?
Does it work in generic_mourn_inferior?

Except lookie there:

void
generic_mourn_inferior (void)
{ 
  extern int show_breakpoint_hit_counts;

  inferior_ptid = null_ptid;
  ...

The AIX configuration totally calls this function from
child_mourn_inferior.  Is this happening before generic_mourn_inferior
gets called?  Or, is AIX somehow getting a different version of
child_mourn_inferior or kill_inferior than I'm seeing?

-- 
Daniel Jacobowitz
CodeSourcery


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