Re: [PATCH] Fix "PC register is not available" issue

[Pedro Alves <palves at redhat dot com>]

On 04/08/2014 06:10 PM, Eli Zaretskii wrote:
>> Date: Tue, 08 Apr 2014 17:42:56 +0100
>> From: Pedro Alves <palves@redhat.com>
>> CC: brobecker@adacore.com, gdb-patches@sourceware.org
>>
>> I'd be very curious to see the backtrace you get
>> for the failing thread in your test case (I guess emacs?).
> 
> Yes, it's Emacs.  Do you mean the backtrace I see when debugging
> natively?

Yes, but you'll need to use the patch I attached, not yours.
When SuspendThread fails, the warning says which thread failed.
The next "continue", "next", whatever will fail when that
happens (just once, so you can continue debugging as usual
in case you're in the middle of a real debug session).  At
that point, "info threads", see which is the gdb thread id
for the thread that failed, switch to it, and get a backtrace,
like I showed in the previous email.

> Because when debugging Emacs with gdbserver, I cannot
> reproduce the problem with SuspendThread.

You mean you can't get the warning in GDBserver's console,
or you don't see the "PC register is not available" issue?
Even if the exact test case as in the PR (and as I attached
to the previous email) -- that is, one that continues banging
in a loop until the failure triggers?  Or you mean with
emacs?

As I mentioned in the previous email, you won't get the
"PC register not available" issue with GDBserver because GDBserver's
thread_rec returns the thread's info structure anyway even if
SuspendThread failed, unlike GDB, which returns NULL.  If
the SuspendThread issue triggers, then the
GetThreadContext/SetThreadContext issue should trigger too.
But, GDBserver actually currently ignores SetThreadContext
fails ...:

static void
i386_set_thread_context (win32_thread_info *th, DEBUG_EVENT* current_event)
{
  if (debug_registers_changed)
    {
      struct i386_debug_reg_state *dr = &debug_reg_state;
      th->context.Dr0 = dr->dr_mirror[0];
      th->context.Dr1 = dr->dr_mirror[1];
      th->context.Dr2 = dr->dr_mirror[2];
      th->context.Dr3 = dr->dr_mirror[3];
      /* th->context.Dr6 = dr->dr_status_mirror;
	 FIXME: should we set dr6 also ?? */
      th->context.Dr7 = dr->dr_control_mirror;
    }

  SetThreadContext (th->h, &th->context);
}



Given I see different backtraces on the same machine in native vs
gdbserver debugging of the same test, and that in gdbserver's case the
failing thread appears to always be further down into thread termination,
it may just be that your machine is a little slower or faster than
mine, and it's harder to stop threads at exactly within the time window
when the SuspendThread problem can trigger.

>> +		    /* We get Access Denied (5) when trying to suspend
>> +		       threads that Windows started on behalf of the
>> +		       debuggee, usually when those threads are just
>> +		       about to exit.  */
>> +		    if (err != ERROR_ACCESS_DENIED)
>>
>> I've shown above that whether it was Windows or the program
>> itself that started the threads is irrelevant, it'd be good to 
>> reword this comment.
> 
> OK.  But now I'm confused: what is the conclusion from what you saw?

My conclusion so far is that this happens exactly when we try to
suspend a thread that is already half-dead, no matter who started it,
and that we do need your patch to GDB, and that GDBserver will also
need to the patched.  I'm just curious to see your emacs backtrace
to 99% confirm that it's the same thread-exiting scenario, mainly
to put any doubts to rest, for us and for future generations (the
archives).

-- 
Pedro Alves