Re: Gdb in emacs 24

[Lluís]

Tom Tromey writes:

>>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:
>>> Wouldn't it be more user-friendly to just ask for the name of the executable
>>> after M-x gdb, compose the correct arguments to GDB automatically?

Stefan> That's an option.  But I'd prefer if we tried to make the current
Stefan> behavior work well, instead.  E.g. it could warn the user when it
Stefan> detects a "--fullname" or "--annotate=3".  And/or gdb-mi could try and
Stefan> notice when GDB doesn't seem to behave according the its expectations
Stefan> and output a warning about a possibly missing "-i mi".

> Another option would be to have Emacs send commands to gdb at startup to
> put it in the right mode.  I don't know if this is possible right now,
> but we could surely make it so.  I can do the gdb side if someone is
> willing to work with me on the Emacs side.

There seems to be no obvious command in gdb to get the current interpreter. The
closest match is routine 'top_level_interpreter', but there is no command to get
that.

There also seems to be no obvious command to set MI as the current interpreter
for all future commands.


What I have found available as commands is:

* set annotate

  Sets the annotation level on all future commands.

* interpreter-exec

  Executes the given command with the given interpreter. Looking at its code
  ('interpreter_exec_cmd'), it's pretty easy to refactor a few lines of code to
  create a new command (e.g., "set interpreter") to set the current interpreter
  on all future commands (can be set up in '_initialize_interpreter').


Assuming this must work without modifying gdb, here's a possible solution:

* set annotate 0

  Disable annotations, so that we can forget about them even if the user did
  actually set them in the cmdline.

* interpreter-exec mi <command>

  Execute each command under the MI interpreter, even if the user did not
  actually set it up in the cmdline.

  Even if not optimal, the cost of setting the interpreter on a per-command
  basis (as opposed to setting the current interpreter for all future commands)
  should not have a noticeable impact on performance.

Two questions remain open:

* What to do if the user ever passed "-i=tui" in the gdb cmdline (which seems to
  make MI unusable even through "interpreter-exec").

  This can be worked around by silently appending any other interface option in
  the cmdline when starting gdb. If we always appended "-i=mi", then
  "interpreter-exec" no longer needs to be used.

* Should user-issued commands in the gdb buffer use the mi or console
  interpreter?

  If it were mi, no problems, apply same approach as above. If it were the
  console interpeter (append "-i=console" when starting gdb; see above), there
  would still be a need for the "interpreter-exec" command.


Hope it helps.

Lluis  

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth