Re: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement

[Doug Evans <dje@google.com>]

On Mon, Dec 1, 2008 at 1:21 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> Hi Doug,
>
> I'd like to bring a current GDB deficiency to your attention, in
> case it affects anything related to this patch.
>
> If GDB stops due to a signal instead of hitting the dummy frame
> breakpoint, and you have set GDB to restore the state
> automatically with "set unwindonsignal on", and the thread
> that reported the signal (say a SIGSEGV) was *not* the same that was
> doing the infcall, GDB will currently restore the old context to the
> wrong thread (seen by inspection, having really tried it).
>
> Not having studied the patch yet, I'm just wondering if your changes
> would make it easier or harder to fix this, or if you could be
> extending the problem by possibly restoring things in the wrong
> thread as well.

Heh.  My patch serendipitously has the following to catch another case
I was seeing where the current thread unexpectedly changed.

  if (! ptid_equal (this_thread->ptid, inferior_thread ()->ptid))
    {
      /* We've switched threads.  Perhaps this shouldn't happen, but we
         protect ourselves anyway.
         There's no point in restoring the inferior status,
         we're in a different thread.  */
      discard_cleanups (inf_status_cleanup);
      discard_inferior_status (inf_status);
      dummy_frame_discard (dummy_frame);
      error (_("\
The current thread has switched while making a function call from GDB.\n\
The state of the function call has been lost.\n\
It may be recoverable by changing back to the original thread\n\
and examining the state."));
    }

I need fix my patch to save the calling thread's ptid
(this_thread->ptid) before resuming execution in case the thread dies.
I think I shouldn't call dummy_frame_discard here too.
And I also need to change the comment to document why the current
thread can switch, because it _can_ happen. :-)
I'll prepare a new version of my patch, and include a testcase to
handle the situation you mention.  Thanks!