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

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Tue, 08 Apr 2014 18:36:37 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> 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.

I can know which thread's suspension fails even without the patch,
because GDB immediately announces its exit.  Is the patch just for
showing the thread ID, or is it needed for something else?

> > 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?

The former, of course.

> 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?

I mean with Emacs.  The PR test case is an artificial toy program
which also floods the system with threads.  I wouldn't consider it a
serious real-life use case.

> 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.

I think multiple cores also come into play here.  (My machine is Core
i7.)

> > 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).

OK, I will try to get that info.