Community
Participate
Working Groups
When we are doing scripting in the GDB console, we are locking GDB waiting for our scripting commands. If the UI sends any commands during that time, those commands will be swallowed as part of the script and the UI will hang. This is a problem that CDI has as well. I believe the problem is worse for DSF-GDB because of non-stop. In non-stop, we can be scripting away in the console, when suddenly an MI event will cause the UI to send MI commands, and everything will break. Currently I had two ideas: 1- When we are in scripting mode, if we realize we are going to send any command that is not a scripting command (not a RawCommand), we force the script to abort by sending an "end" command. This is not nice to the user, but it sure is better than the entire UI hanging. 2- We could try to handle the scripting in Eclipse until all script commands have been collected, and then send them all in one go to GDB.
(In reply to comment #0) 3 - (A variation on 1). If we realize that we are going to send any non-scripting command, return an error for that command. It's also not nice to the user but it will allow the user to keep writing a script, and the GUI can be refreshed later. This is a pretty ugly protocol interaction. It's a strong argument for having separate protocol channels for CLI and MI commands. BTW, I really like the idea of having the console recognize the start of scripting e.g. by looking for the "define/end" commands, then sending them all at once. Even then it may be good to generate an error when a non raw command is sent while in seconary prompt.
(In reply to comment #1) > (In reply to comment #0) > > 3 - (A variation on 1). If we realize that we are going to send any > non-scripting command, return an error for that command. It's also not nice to > the user but it will allow the user to keep writing a script, and the GUI can > be refreshed later. That is probably even easier to implement. I can give it a try to see how it feels to a user. > This is a pretty ugly protocol interaction. It's a strong argument for having > separate protocol channels for CLI and MI commands. But that would require support from GDB. Right now, once we are in scripting mode, GDB is only accepting those commands. > BTW, I really like the > idea of having the console recognize the start of scripting e.g. by looking for > the "define/end" commands, then sending them all at once. There are a couple of disadvantages with this, of course: 1- we are not future proof for new commands that trigger the secondary prompt. For example, the 'actions' command also triggers a secondary prompt. We'll have to be careful to check for any such command. 2- We don't get the GDB parsing, so we have to assume that any RawCommand succeeds up to the 'end' command. That may actually be the way GDB does things anyway. But those issues are not such a big deal, so it would be nice to give this a try. > Even then it may be > good to generate an error when a non raw command is sent while in seconary > prompt. Even if GDB will accept this command? Sending such commands would allow the UI to keep up.
(In reply to comment #2) > > Even then it may be > > good to generate an error when a non raw command is sent while in seconary > > prompt. > > Even if GDB will accept this command? Sending such commands would allow the UI > to keep up. > I'm sorry I don't know the user cases for the secondary prompt, so I was just assuming that when there is a secondary prompt, the UI commands would not receive a response... thus leading the the UI deadlock.
(In reply to comment #3) > (In reply to comment #2) > > > Even then it may be > > > good to generate an error when a non raw command is sent while in seconary > > > prompt. > > > > Even if GDB will accept this command? Sending such commands would allow the UI > > to keep up. > > > > I'm sorry I don't know the user cases for the secondary prompt, so I was just > assuming that when there is a secondary prompt, the UI commands would not > receive a response... thus leading the the UI deadlock. That is right. But when reading "BTW, I really like the idea of having the console recognize the start of scripting e.g. by looking for the "define/end" commands, then sending them all at once. Even then it may be good to generate an error when a non raw command is sent while in seconary prompt." I assumed you meant that even if we listen for "define/end", we should still generate an error for the non-raw commands arriving during the scripting. But the value of handling the scripting in Eclipse and then sending everything at once to GDB is to allow GDB to accept other commands during that time, so as to allow the UI to keep responding nicely. But maybe you meant something else with the sentence above?
(In reply to comment #2) > 2- We don't get the GDB parsing, so we have to assume that any RawCommand > succeeds up to the 'end' command. That may actually be the way GDB does things > anyway. For information, GDB does do parsing for each secondary command, as it is sent from the user. For example, the 'actions' command (for tracepoints) triggers a secondary prompt; the secondary commands are then limited to 'collect' and 'while-stepping', any other command will immediately be rejected by GDB with a warning. We would not be able to do this 'live' if we buffered the commands. Worst, if an invalid 'collect' is given (e.g., for a variable that does not exist), GDB immediately rejects it and stops the secondary prompt. Again, if we buffer we won't be able to do this. But that does not mean we shouldn't buffer, it just means the error will be show a little later. Also, I found that there was some discussion about this issue on the GDB mailing list. Apparently the Apple GDB even has some support for this problem in MI. Please see: http://sourceware.org/ml/gdb/2005-07/msg00088.html
