This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Bail out of processing stop if hook-stop resumes target / changes context
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Fri, 11 Sep 2015 15:55:58 +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> <55F086B0 dot 9040701 at redhat dot com>
Pedro Alves <palves@redhat.com> writes:
> We don't have infrastructure to run command lists like that. The
> hook-stop might involve several execution commands, for
> instance. See:
> https://sourceware.org/ml/gdb-patches/2011-09/msg00037.html
> And what motivated it:
> https://sourceware.org/ml/gdb-patches/2011-06/msg00158.html
Yeah, I didn't strongly believe we have such infrastructure, so I raised
that question.
>
> 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
It sounds natural to move interpreter and run control to separate
threads. It may be hard to convert single-threaded gdb to a
multi-threaded version. Note that I am not against this direction.
--
Yao (éå)