This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]