This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Bail out of processing stop if hook-stop resumes target / changes context
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 09 Sep 2015 20:21:20 +0100
- Subject: Re: [PATCH] Bail out of processing stop if hook-stop resumes target / changes context
- Authentication-results: sourceware.org; auth=none
- References: <1439836415-22008-1-git-send-email-palves at redhat dot com> <86zj1n1ycy dot fsf at gmail dot com> <55DC8E2C dot 6010308 at redhat dot com> <86twrkzwf4 dot fsf at gmail dot com>
On 08/27/2015 02:35 PM, Yao Qi wrote:
>>> I am wondering why don't we let interpreter in async to execute
>>> stop_command, and we simply return here. In this way, we don't have to
>>> know whether stop_command resumes the target or switches the thread.
>>> Once there is no event from event loop, the target really stops and
>>> hook-stop is already executed.
>> Not sure I understood the suggestion -- I don't see how that would end
>> up being different. If the hook-stop does "continue&", then we still need
>> to know that the target was resumed. Likewise if the hook-stop just
>> does "thread N" and thus switches to another thread -- there's no
>> execution involved in that case so seems to me interpreter async/sync
>> makes no difference.
> I was thinking that why do we need stop_id or stop_context here. We can
> let interpreter to execute hook-stop commands in an async way, and GDB
> reads events out of event loop, until all events are consumed. In this
> way, do we still need stop_id or stop_context?
We don't have infrastructure to run command lists like that. The
hook-stop might involve several execution commands, for
And what motivated it:
I don't currently see any real benefit in splitting interpreter
command execution to a bigger and more complicated state machine
like I was originally attempting. I've been thinking that longer
term, it'd be simpler/saner if we split run control and the
interpreter to separate threads. I actually have a prototype
branch that makes it possible to have multiple consoles/CLIs
simultaneously, and there, to make it possible to handle
pagination and queries correctly in all consoles, I made gdb
run each console's interpreter in its own thread. See
warning, lots of hacks in place. This fix actually comes out
of that branch (the "fix hook-stop" commit ), though the fix
there was based on proceed call counts. I came up with counting
stops instead of proceeds/resumes while trying to clean that up and
writing the test, which uncovered the need for handling thread
switching too etc.
 - https://github.com/palves/gdb/commit/f1505f9a6cf5097c83771d373e512fa9c819aa7a