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

[Eli Zaretskii <eliz at gnu dot org>]

Ping!  If there are no further suggestions, I'd like to commit the
changes posted in this thread.

> Date: Mon, 31 Mar 2014 18:31:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> > Date: Fri, 28 Mar 2014 21:30:10 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> > 
> > > Date: Fri, 28 Mar 2014 17:49:13 +0000
> > > From: Pedro Alves <palves@redhat.com>
> > > CC: brobecker@adacore.com, gdb-patches@sourceware.org
> > > 
> > > >> Why bother calling SetThreadContext at all if we just killed
> > > >> the process?
> > > > 
> > > > See my other mail and Joel's response.
> > > 
> > > Not sure what you mean.  TerminateProcess is asynchronous, and
> > > we need to resume the inferior and collect the debug events
> > > until we see the process terminate.  But, my question is
> > > why would we write the thread's registers at all if we
> > > just told it to die?  Seems to be we could just skip
> > > calling SetThreadContext instead of calling it but
> > > ignoring the result.
> > 
> > If you say so, I don't know enough about this stuff.
> 
> Actually, upon second thought: we continue the inferior after
> TerminateProcess call to let it be killed, right?  If so, shouldn't we
> continue it with the right context?
> 
> > > >> Sounds like GDBserver might have this problem too.
> > > > 
> > > > If there's an easy way to verify that, without having 2 systems
> > > > talking via some communications line, please tell how, and I will try
> > > > that.
> > > 
> > > Sure, you can run gdbserver and gdb on the same machine, and connect
> > > with tcp.  Just:
> > > 
> > >  $ gdbserver :9999 myprogram.exe
> > > 
> > > in one terminal, and:
> > > 
> > >  $ gdb myprogram.exe -ex "tar rem :9999" -ex "b main" -ex "c"
> > > 
> > > in another.
> > 
> > OK, will try that.
> 
> Funnily enough, I cannot get GDBserver to emit similar warnings in the
> same situation.  I don't understand the reasons for that, since the
> code is very similar, and with a single exception, we do check the
> return values of calls to GetThreadContext, SetThreadContext, and
> SuspendThread in GDBserver.  But the fact remains that no warnings
> about these threads are ever seen when debugging remotely.  I do see
> the extra threads under GDBserver as well.
> 
> Does anyone have any further ideas?