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

[Pedro Alves]

On 03/28/2014 05:35 PM, Eli Zaretskii wrote:
>> Date: Fri, 28 Mar 2014 14:50:31 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
>>
>> On 03/26/2014 06:49 PM, Eli Zaretskii wrote:
>>> This describes the results of my looking into this issue, given the
>>> comments and suggestions by Joel and Pedro.  Sorry about the length.
>>>
>>>> I didn't mean to change the behavior - only hide the warning.
>>>> In this case, if it is normal that we can't suspend the thread,
>>>> then there is no point in warning (scaring) the user about it.
>>>> I would only generate a warning if something abnormal that we should
>>>> fix occured.
>>>
>>> The patch near the end of this message indeed includes code to ignore
>>> the warning in these cases.
>>>
>>>> I see that the GetThreadContext call (do_windows_fetch_inferior_registers)
>>>> doesn't check for errors (I think it should (*)).  It'd be interesting to know whether gdb can
>>>> actually read the registers off of this thread, and if so, what's the
>>>> thread's backtrace like.
>>>
>>> I added CHECK to that call to GetThreadContext.  It never produced a
>>> warning in all my testing, and it looks like we do succeed to get the
>>> registers.  At least the registers of 2 such threads show different
>>> contents, and the EIP value is consistent with what "info threads"
>>> displays.
>>
>> It isn't clear to me whether you're saying that you saw the
>> SuspendThread failure trigger in all your new testing, so that
>> we'd know for sure whether GetThreadContext suceeds in that case,
>> or whether it might have been that you just were "lucky" enough
>> to not trigger the SuspendThread failure issue.
> 
> The former.
>
>> Does your patch fix the test case in PR14018, without producing
>> a CHECK warning from the new CHECK in GetThreadContext you've
>> added?
> 
> Yes.

Ah, excellent!  Thank you.  Please remember adding the PR number
to the ChangeLog entry then.


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

> 
>>> Finally, here's the full patch.  I hope this research answered all the
>>> questions, and we can now get the patch in.
>>
>> I'm not sure it did, but in any case the patch looks good to me.
> 
> If that's an approval, I will happily commit the changes.

It's an approval from my end.

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

-- 
Pedro Alves