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: Joel Brobecker <brobecker at adacore dot com>
- Cc: palves at redhat dot com, gdb-patches at sourceware dot org
- Date: Tue, 08 Apr 2014 05:44:26 +0300
- Subject: Re: [PATCH] Fix "PC register is not available" issue
- Authentication-results: sourceware.org; auth=none
- References: <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> <5342DBBC dot 4090500 at redhat dot com> <83lhvh6lqi dot fsf at gnu dot org> <20140407213913 dot GE4250 at adacore dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 7 Apr 2014 14:39:13 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
>
> > But the warnings I was talking about are output with OUTMSG, which
> > doesn't depend on debug_threads. Here's an example:
> >
> > static void
> > suspend_one_thread (struct inferior_list_entry *entry)
> > {
> > struct thread_info *thread = (struct thread_info *) entry;
> > win32_thread_info *th = inferior_target_data (thread);
> >
> > if (!th->suspended)
> > {
> > if (SuspendThread (th->h) == (DWORD) -1)
> > {
> > DWORD err = GetLastError ();
> > OUTMSG (("warning: SuspendThread failed in suspend_one_thread, "
> > "(error %d): %s\n", (int) err, strwinerror (err)));
> >
> > Did I miss something?
>
> This code not going to be used at all if you debug through GDBserver
> (it's the code in remote.c that does).
Sorry, I don't understand: remote.c is not specific to Windows, so it
cannot include any Windows-specific calls like SuspendThread.
> But if the GDBserver code does the same thing as windows-nat in
> terms of inferior management, it might trigger the same error and
> output them on GDBserver's stdout/stderr if --debug is enabled.
Again, I don't see where --debug comes into play here. Can you tell
me what am I missing?
> Usually, we try to keep the GDB and GDBserver code in sync, and that
> means that we fix a problem in inferior management, it's a good bet
> that the same problem exists on both sides.
As I said, I don't see the same problem in the server.
> I might be able to take a look sometime next week. I think the issue
> we'll have is with testing, since the problem is not necessarily always
> reproduceable in Eli's scenario, and he would need to debug repeatedly
> with GDBserver in order to gain a good level of confidence that the
> problem is gone for good.
I can reproduce it with some effort, so verifying a fix is not a
problem.