RE: Reverse debugging

Marc Khouzam
2009-07-22T17:46:47Z

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: Saturday, July 18, 2009 12:00 AM
> To: Nick Roberts
> Cc: Marc Khouzam; Hui Zhu; gdb@sources.redhat.com; Michael Snyder
> Subject: Re: Reverse debugging
>
> On Sat, Jul 18, 2009 at 01:06:36PM +1200, Nick Roberts wrote:
> > It seems strange not to use a tty for the console since it
> is a terminal. It
> > allows you to change the terminal mode, although admittedly
> I've not found a
> > need for this. Also if you wanted to use readline, I guess
> it would need a
> > tty.
>
> I've found it works much better to handle any readline-like behavior
> in the front end; then use -interpreter-exec to talk to GDB. This
> lets you reliably get MI notifications for actions, etc.

If I understand correctly your point is that using GDB to handle
readline behavior will lockup the GDB-frontend communication and will
delay any MI notifications. If that is what you meant, then I wasnted
to bring up the fact that such a problem is occuring now with
scripting (with the 'define' command).

If a user uses the 'define' command in the eclipse console, GDB is now
locked listening on the secondary prompt ('>'). If any MI commands
happened to be sent to GDB during that time, they get swallowed and
Eclipse gets all messed up.

I was considering handling the secondary prompt within eclipse and then
sending all those sub commands to GDB at once. To do this, I was
wondering a couple of things:

- is there anyway that something type at the secondary prompt
can cause a failure? What I mean is: is it true that
except for ^C and 'end', anything will be accepted at the
secondary prompt, and the next line will be a new secondary
prompt.

- can I 'undefine' a user command?

- are there many commands that trigger the secondary prompt?
I am aware of 'define' and 'actions'

Thanks

Marc