This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix "PC register is not available" issue
- From: Eli Zaretskii <eliz at gnu dot org>
- To: palves at redhat dot com
- Cc: brobecker at adacore dot com, gdb-patches at sourceware dot org
- Date: Mon, 31 Mar 2014 18:31:43 +0300
- Subject: Re: [PATCH] Fix "PC register is not available" issue
- Authentication-results: sourceware.org; auth=none
- References: <83txawa9wk dot fsf at gnu dot org> <20140318161608 dot GD4282 at adacore dot com> <83pplja2h9 dot fsf at gnu dot org> <20140318165413 dot GE4282 at adacore dot com> <834n2kztfw dot fsf at gnu dot org> <53358C37 dot 9050907 at redhat dot com> <83a9cafcpz dot fsf at gnu dot org> <5335B619 dot 6040605 at redhat dot com> <8361myfa6l dot fsf at gnu dot org>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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?