RE: [dsdp-dd-dev] DSF design question

["Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>]

> > Well, this will cause user-defined commands that switch 
> > threads to break. Fortunately,
> > patches to make GDB notify when current thread changes are 
> > been discussed on gdb-patches@
> > now. But actually, I think that UI and CLI console should 
> > have the same notion of selected
> > thread and frame -- having two different selected threads 
> > will be extremely confusing.
>  
> I have never used GDB from the command line, so my assumption 
> that we could parse the CLI commands to detect thread 
> switches may have been rather naive.  Your use case of 
> user-defined commands is certainly one I haven't thought of.  
> A notification from GDB when the selected thread changes 
> would help, although to use them DSF-GDB would have to add 
> special handling of CLI commands to force it to wait for this 
> event before sending another command (either CLI or MI).  

I hadn't payed attention to the "user-defined commands" point.
Francois and I have had a look at such things a little while back
and found that the CDT also does not handle user-defined commands
properly.  Sourcing a script also causes the same issues.

We were discussing a type of "full-refresh" once a script is parsed,
so as to get DSF synched with the changes caused by the console script.
This may not be possible for user-defined commands though if we cannot
tell that a user-defined command has just been run.
Does GDB have some differentiating output after a user-defined command?

Marc