This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Bail out of processing stop if hook-stop resumes target / changes context


Hi Yao,

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
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

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
https://github.com/palves/gdb/tree/palves/console, though
warning, lots of hacks in place.  This fix actually comes out
of that branch (the "fix hook-stop" commit [1]), 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.

 [1] - https://github.com/palves/gdb/commit/f1505f9a6cf5097c83771d373e512fa9c819aa7a

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]