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: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: brobecker at adacore dot com, gdb-patches at sourceware dot org
- Date: Fri, 28 Mar 2014 17:49:13 +0000
- Subject: Re: [PATCH] Fix "PC register is not available" issue
- Authentication-results: sourceware.org; auth=none
- References: <83txawa9wk dot fsf at gnu dot org> <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>
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