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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Monday 16 June 2008 20:25:18 Marc Khouzam wrote:
> 
> > > 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?

No -- and will it help? If the use case with two windows is important,
then doing full-refresh after each user-defined command will bring both
windows in the same state. It seems the notification is a better approach.

Of course, how common are user-defined commands that change thread or
frame is a question, but I presume it's possible.

- Volodya