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: Joel Brobecker <brobecker at adacore dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: palves at redhat dot com, gdb-patches at sourceware dot org
- Date: Mon, 7 Apr 2014 09:58:14 -0700
- Subject: Re: [PATCH] Fix "PC register is not available" issue
- Authentication-results: sourceware.org; auth=none
- References: <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> <83ioqucrkw dot fsf at gnu dot org> <83ha6887re dot fsf at gnu dot org>
> 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