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

[Joel Brobecker <brobecker@adacore.com>]

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

FWIW, I think you can go ahead. Your patches seem to be an improvement,
and I don't see how they could make things worse should we want to
work on another way to implement this part of the code again.

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

Sure, but what context would that be?

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

-- 
Joel