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

Eli Zaretskii eliz@gnu.org
Tue Apr 8 02:44:00 GMT 2014


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



More information about the Gdb-patches mailing list