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

[Pedro Alves <palves@redhat.com>]

On 03/31/2014 04:31 PM, Eli Zaretskii wrote:
>> 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?

I don't think the threads are going to run whatever context
you set them them to.  They'll surely die before ever getting
scheduled to run any further userspace code?

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

GDBserver's warnings are guarded by 'if (debug_threads)' (see OUTMSG2).
That means you'll need to start gdbserver with --debug to see them.
Did you do that?

-- 
Pedro Alves