This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Reset inferior_ptid after "kill"
- From: Daniel Jacobowitz <drow at false dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 22 Jan 2006 20:00:06 -0500
- Subject: Re: [RFA] Reset inferior_ptid after "kill"
- References: <20051219184122.GS991@adacore.com>
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