This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 9/9] enable target-async
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 09 Dec 2013 12:01:30 +0000
- Subject: Re: [PATCH v4 9/9] enable target-async
- Authentication-results: sourceware.org; auth=none
- References: <1382464769-2465-1-git-send-email-tromey at redhat dot com> <1382464769-2465-10-git-send-email-tromey at redhat dot com> <52828856 dot 9070904 at redhat dot com> <87li0qve9y dot fsf at fleche dot redhat dot com> <528A2E8B dot 9050300 at redhat dot com> <87r49piu9z dot fsf at fleche dot redhat dot com>
On 12/06/2013 08:44 PM, Tom Tromey wrote:
>>>>> -# so the stop reason is printed into MI uiout an.
>>>>> -if {$async} {
>>>>> - set reason "end-stepping-range"
>>>>> -} else {
>>>>> - set reason ""
>>>>> -}
>>>>> +set reason "end-stepping-range"
>>>
> Pedro> I'm a little confused by this one. Isn't it still necessary
> Pedro> for targets that don't do async?
>
> I re-examined this and I think the answer is much simpler than all the
> incorrect things I wrote before.
>
> git master gdb in the default (target-async off) mode prints:
>
> *stopped,frame={addr="0x0000000000400597",func="callee4",args=[],file="../../../binutils-gdb/gdb/testsuite/gdb.mi/basics.c",fullname="/home/tromey/Space/SecondArcher/binutils-gdb/gdb/testsuite/gdb.mi/basics.c",line="26"},thread-id="1",stopped-threads="all",core="0"
>
> The gdb from this branch prints:
>
> *stopped,reason="end-stepping-range",frame={addr="0x0000000000400597",func="callee4",args=[],file="../../../binutils-gdb/gdb/testsuite/gdb.mi/basics.c",fullname="/home/tromey/gnu/gdb/devel/binutils-gdb/gdb/testsuite/gdb.mi/basics.c",line="26"},thread-id="1",stopped-threads="all",core="3"
>
>
But that was on GNU/Linux, where the backend will always be async, right?
> That is, gdb now emits reason="end-stepping-range". This is a
> compatible change to the output. This explains the patch: now the
> !$async case is no longer hit.
The question is whether that is actually true on all the other
backends/targets that _don't_ know how to async. Like e.g.,
Windows.
--
Pedro Alves