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: Mon, 07 Apr 2014 18:09:16 +0100
- 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> <5335B619 dot 6040605 at redhat dot com> <8361myfa6l dot fsf at gnu dot org> <83ioqucrkw dot fsf at gnu dot org>
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