Hi Marc,
I think you've pretty much answered the question (though I'm not sure
from who), I can try to fill in the rest.
Marc Khouzam wrote:
2. Is there a mechanism to atomically execute a sequence of commands?
By that, I mean that the each next command can be only constructed when
the output of the previous one is known, and we don't want any other
command to be executed until the sequence is fully done?
org.eclipse.dd.dsf.concurrent.Sequence.java
You can see an example of it in
org.eclipse.dd.gdb.internal.provisional.launching.ServicesLaunchSequence.java
I'm afraid I still don't see where it ensures atomicity. In executeStep,
we call next step's execute method, with a RequestMonitor, and when request
monitor's handleCompleted is called, we execute next step.
What will prevent some other code to send a gdb command between the
calls to 'execute' of the next step and the call to rm's 'handleCompleted'?
I guess I didn't answer your first question right. From what I see,
you are right that Sequence does not give atomicity. But it is the class we
use to execute multiple commands in sequence (just not atomically.)
I guess I jumped the gun on your question when I read
By that, I mean that the each next command can be only constructed when
the output of the previous one is known,
which is fulfilled by Sequence.
and we don't want any other
command to be executed until the sequence is fully done?
This part of your question, I missed.
I'm not sure if there is a way to do that. But my DSF knowledge is far
from complete.
Currently,. there is no way to "lock" the target in order to allow a
single client to send a set of commands atomically. We really haven't
had a use case for it. The times where atomicity is needed is when
changing the protocol state (using -thread-select and
-stack-frame-select) and we solve those by translating context in the
command into these context-switching commands.
3. AbstractMIControl.queueCommand will send -thread-select as necessary.
Is there any place where the GDB current thread is reset to what it
was before the command is executed?
I don't think so.
If not, it seems that the current thread
seen by the user in the GDB console will potentially be different from what
is shown in the UI.
-thread-select will also change the thread for the GDB console, so the console
and the UI should remain consistent, no?
Yes, but assume this use case. GDB is in non-stop mode, and user is looking at
thread X. In the meantime, thread Y is also stopped. It is probably desirable
to get some information about thread Y, for example the stack, to also show it
to the user. At the same time, it's probably not desirable to change the
current thread to Y. After all, there's already stopped thread X and user
is looking at its data. So, it's best to get the stack frames for Y without
changing the current thread either in UI or in GDB. I think not changing the current
thread in UI is easy, but without code to restore thread back, the current
thread in GDB will change.
I didn't know you were setting me up for a non-stop use case :-)
We haven't changed DSF to support non-stop yet. We are actually working on it
right now, so your questions are helpful.
Every time a command is queued in AbstractMIControl.queueCommand, it comes
with information indicating for which thread it is meant for. So, I believe
that if we changed the GDB current thread as your use case requires, we would
automatically issue a new -thread-select to change the thread back, before
sending the next GDB command that is being queued (if necessary.)
The important thing here is that GDB does not change its current thread on
its own, which I believe you are taking care of for non-stop mode.
I guess my previous answer was wrong again :-)
The GDB current thread is in fact reset, and it this is done by the same
mechanism that changed it in the first place.
There's another issue -- I think we don't want to allow the user to emit any GDB
commands in the console while the current thread is temporary changed -- which
brings us back to the question how atomic sequences are implemented.
This is a valid point. We didn't discuss the console with non-stop yet...
We would have to apply the thread-select solution above to console commands.
Maybe we already do, actually. I'm not sure, but I'll check.
Such a solution would still work with older versions of GDB, so we would not
have to if/else that code, which will prove pretty clean. In fact, I can probably
make the changes now, without having to wait for the new version of GDB.
Make sense?
Marc
The current thread problem in the console is indeed a problem not just
in non-stop mode but even with current DSF-GDB implementation. I filed
a bug for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=192742
quite a ways back, though it's one of many problems with the GDB CLI
console.
The proper DSF-style solution I believe is to have the console itself
track its current thread-id and stack frame. Just like any other
client to the command interface, the console should supply the context
that it wants its commands executed in. As far as I know there are
only a couple commands that switch the current context in the CLI
interface so the implementation of the state tracking could be done by
parsing the commands its sending to GDB and looking for "thread ...",
etc.
On the down side, this solution could actually be somewhat counter
productive, because it is useful to have the currently selected thread
and frame in the console match the currently selected context in Debug
view. We can solve this by having the console listen to the currently
selected context and explicitly emit "thread ..." and "frame ..."
commands to the console. It would have the benefit of making it very
clear to the console user what thread he's looking at and it could also
be turned off with a toggle.
Cheers,
Pawel
|
