Re: Gdb in emacs 24

Re: Gdb in emacs 24

[Nick Roberts]

> Try using gud-gdb instead.

How will that help with emacs development?

Re: Gdb in emacs 24

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

>> Try using gud-gdb instead.
>
> How will that help with emacs development?

What does this have to do with emacs development?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gdb in emacs 24

[Nick Roberts]

Gdb in Emacs 24 uses MI not annotations.  You need:

(defun gdb-pad ()
  "Debug the simulation"
  (interactive)
  (gdb "gdb -cd=/long/path -i=mi --args /long/path/opp_run args"))

Re: Gdb in emacs 24

[Andrea Crotti]

Nick Roberts <nickrob@snap.net.nz> writes:

> Gdb in Emacs 24 uses MI not annotations.  You need:
>
> (defun gdb-pad ()
>   "Debug the simulation"
>   (interactive)
>   (gdb "gdb -cd=/long/path -i=mi --args /long/path/opp_run args"))

Thanks a lot, that works and it's nice, but now I can't give interactive
commands anymore.
Every time I try to type something in the gdb buffer it start the
program, and C-c C-n doesn't work anymore either...

Something else important that changed maybe?

Gdb in emacs 24

[Andrea Crotti]

I'm using now emacs from the trunk (in the signature the full version)
and it works wonderfully for everything.  The only thing that doesn't
work is the gdb.

I have an elisp function to call GDB (just a shortcut):

--8<---------------cut here---------------start------------->8---
(defun gdb-pad ()
  "Debug the simulation"
  (interactive)
  (gdb "gdb -cd=/long/path --annotate=3 --args /long/path/opp_run args"))
--8<---------------cut here---------------end--------------->8---

And when I run it I get things like
--8<---------------cut here---------------start------------->8---
pre-prompt
       prompt
                             
post-prompt
                                            
error-begin
Undefined command: "1-inferior-tty-set".  Try "help".
                                                                                                                 
error
--8<---------------cut here---------------end--------------->8---

Looks like an error of gdb, this is for completeness the version of gdb
on this machine...

--8<---------------cut here---------------start------------->8---
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
--8<---------------cut here---------------end--------------->8---

Any idea?
Is there any emacs-friendly way to navigate in the bug tracking system
and see if something is already there about?

And by the way is not so easy to find the web interface of the bug
tracking system, I only saw it the first time I when I actually reported
a bug (dreaming about an org-mode based bug tracking system).

Thanks a lot for the great work,
Andrea

-- 
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0)
 of 2011-03-04 on plaetekopp

Re: Gdb in emacs 24

[Eli Zaretskii]

> From: Andrea Crotti <andrea.crotti.0@gmail.com>
> Date: Tue, 08 Mar 2011 09:07:32 +0100
> 
> 
> I'm using now emacs from the trunk (in the signature the full version)
> and it works wonderfully for everything.  The only thing that doesn't
> work is the gdb.
> 
> I have an elisp function to call GDB (just a shortcut):
> 
> --8<---------------cut here---------------start------------->8---
> (defun gdb-pad ()
>   "Debug the simulation"
>   (interactive)
>   (gdb "gdb -cd=/long/path --annotate=3 --args /long/path/opp_run args"))
> --8<---------------cut here---------------end--------------->8---

If you "C-h f gdb RET", you will see that Emacs 24 switched to use the
GDB/MI interface, so the --annotate=3 thingy is no longer TRT, and I'm
quite sure it will interfere in "interesting" ways.

Does the interactive invocation via "M-x gdb" work, or does it fail in
the same way?  If the latter, set debug-on-* non-nil, and post the
traceback.  If the former, modify your gdb-pad to fit the arguments
passed to GDB by the interactive invocation.

> Is there any emacs-friendly way to navigate in the bug tracking system
> and see if something is already there about?

There's a search feature on the bug tracker site, just search for
relevant keywords.

> And by the way is not so easy to find the web interface of the bug
> tracking system, I only saw it the first time I when I actually reported
> a bug (dreaming about an org-mode based bug tracking system).

See admin/notes/bugtracker in the Emacs tree near you, it has all
those details spelled out.

Re: Gdb in emacs 24

[David Reitter]

On Mar 8, 2011, at 3:56 AM, Eli Zaretskii wrote:
> 
> If you "C-h f gdb RET", you will see that Emacs 24 switched to use the
> GDB/MI interface, so the --annotate=3 thingy is no longer TRT, and I'm
> quite sure it will interfere in "interesting" ways.
> 

Actually, the doc string doesn't tell me that at all.  In fact, it gives an undefined COMMAND-LINE argument, and the text refers to an undeclared FILE argument.

I fell for --annotate=3 just like the OP did and, for a long time, just thought that Emacs 24 and GDB 6.3 (as on OS X) were again incompatible.

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?
C-u M-x gdb could ask for the full set of arguments as before.

That's because if you don't give -i mi, it won't work either, without simple-to-understand error message.


===
gdb is an interactive Lisp function in `gdb-mi.el'.

It is bound to <menu-bar> <tools> <gdb>.

(gdb COMMAND-LINE)

Run gdb on program FILE in buffer *gud-FILE*.
The directory containing FILE becomes the initial working directory
and source-file directory for your debugger.

If `gdb-many-windows' is nil (the default value) then gdb just
pops up the GUD buffer unless `gdb-show-main' is t.  In this case
it starts with two windows: one displaying the GUD buffer and the
other with the source file with the main routine of the inferior.

If `gdb-many-windows' is t, regardless of the value of
`gdb-show-main', the layout below will appear.  Keybindings are
shown in some of the buffers.

Watch expressions appear in the speedbar/slowbar.

The following commands help control operation :

`gdb-many-windows'    - Toggle the number of windows gdb uses.
`gdb-restore-windows' - To restore the window layout.

See Info node `(emacs)GDB Graphical Interface' for a more
detailed description of this mode.

Re: Gdb in emacs 24

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Wed, 5 Oct 2011 17:55:34 -0400
> 
> On Mar 8, 2011, at 3:56 AM, Eli Zaretskii wrote:
> > 
> > If you "C-h f gdb RET", you will see that Emacs 24 switched to use the
> > GDB/MI interface, so the --annotate=3 thingy is no longer TRT, and I'm
> > quite sure it will interfere in "interesting" ways.
> 
> Actually, the doc string doesn't tell me that at all.

The very first line of the doc string says:

  gdb is an interactive autoloaded Lisp function in `gdb-mi.el'.
                                                     ^^^^^^^^^
> In fact, it gives an undefined COMMAND-LINE argument, and the text refers to an undeclared FILE argument.

Please submit a bug report about these blunders.

Re: Gdb in emacs 24

[David Reitter]

On Oct 6, 2011, at 1:52 AM, Eli Zaretskii wrote:
> 
> The very first line of the doc string says:
> 
>  gdb is an interactive autoloaded Lisp function in `gdb-mi.el'.
>                                                     ^^^^^^^^^

So, you're now asking users to infer the interface between GDB and Emacs from file names of the source file?

I made a constructive suggestion about how to deal with this sort of issue going forward.

Re: Gdb in emacs 24

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Thu, 6 Oct 2011 06:45:37 -0400
> Cc: emacs-devel@gnu.org
> 
> On Oct 6, 2011, at 1:52 AM, Eli Zaretskii wrote:
> > 
> > The very first line of the doc string says:
> > 
> >  gdb is an interactive autoloaded Lisp function in `gdb-mi.el'.
> >                                                     ^^^^^^^^^
> 
> So, you're now asking users to infer the interface between GDB and Emacs from file names of the source file?

Huh? did you even read the message to which I was responding?  A user
asked why her ELisp function stopped working in Emacs 24.  That
function used "--annotate=3" switch to GDB.  I responded that since
Emacs 24 switched to using the MI interface to GDB, using --annotate
is expected to fail.

IOW, I was trying to explain why --annotate is not going to work.  Is
that something you consider unreasonable?

> I made a constructive suggestion about how to deal with this sort of issue going forward.

I made no comments for that suggestion, FWIW.  I hope you will not
consider my silence a vice.

Re: Gdb in emacs 24

[David Reitter]

On Oct 6, 2011, at 7:25 AM, Eli Zaretskii wrote:

>>> The very first line of the doc string says:
>>> 
>>> gdb is an interactive autoloaded Lisp function in `gdb-mi.el'.
>>>                                                    ^^^^^^^^^
>> 
>> So, you're now asking users to infer the interface between GDB and Emacs from file names of the source file?
> 
> Huh? did you even read the message to which I was responding?  A user
> asked why her ELisp function stopped working in Emacs 24.  That
> function used "--annotate=3" switch to GDB.  I responded that since
> Emacs 24 switched to using the MI interface to GDB, using --annotate
> is expected to fail.


There must be a misunderstanding.  Here's what you said:

> If you "C-h f gdb RET", you will see that Emacs 24 switched to use the
> GDB/MI interface, so the --annotate=3 thingy is no longer TRT, and I'm
> quite sure it will interfere in "interesting" ways.

And I pointed out that you couldn't actually infer the switch to the new interface from the doc string of `gdb'.

You responded by underlining the name of the source file.  

And my point is that this is insufficient to get the user to use a different argument for gdb.  (Clicking on the source file gets me to the definition of `gdb', and I have to scroll to the commentary on page 2 of the source code to find something about MI.   (The commentary actually says " It runs gdb with GDB/MI (-interp=mi)", which would lead me to infer that I don't have to give gdb further arguments on my own!)    Apologies if that wasn't clear.

In general:

1. The user doesn't care about how Emacs GDB and the underlying gdb communicate, and how that changes between Emacs versions - nor should they have to care.

2. The user can't be expected to deal with gdb's command line arguments, beyond the path of the executable anyway.  They're debugging their own program and that's complicated enough.  Tools should be seamless.

3. Don't expect the user to read documentation for Emacs functions between upgrades of Emacs.   Most users, today, won't read documentation at all.  They have to read API documentation for the program their writing, that's enough.

None of these have to do with users being "stupid".  Everyone has attentional limitations.

PS.: thanks to everybody for keeping GDB in Emacs working, even with my ancient version/fork of GDB.  It makes life much easier.

Re: Gdb in emacs 24

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> And I pointed out that you couldn't actually infer the switch to the
> new interface from the doc string of `gdb'.

Fixed in trunk.

Re: Gdb in emacs 24

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Thu, 6 Oct 2011 09:37:45 -0400
> Cc: emacs-devel@gnu.org
> 
> On Oct 6, 2011, at 7:25 AM, Eli Zaretskii wrote:
> 
> >>> The very first line of the doc string says:
> >>> 
> >>> gdb is an interactive autoloaded Lisp function in `gdb-mi.el'.
> >>>                                                    ^^^^^^^^^
> >> 
> >> So, you're now asking users to infer the interface between GDB and Emacs from file names of the source file?
> > 
> > Huh? did you even read the message to which I was responding?  A user
> > asked why her ELisp function stopped working in Emacs 24.  That
> > function used "--annotate=3" switch to GDB.  I responded that since
> > Emacs 24 switched to using the MI interface to GDB, using --annotate
> > is expected to fail.
> 
> 
> There must be a misunderstanding.  Here's what you said:
> 
> > If you "C-h f gdb RET", you will see that Emacs 24 switched to use the
> > GDB/MI interface, so the --annotate=3 thingy is no longer TRT, and I'm
> > quite sure it will interfere in "interesting" ways.

That was part of an attempt to help a user understand why her Lisp no
longer works in Emacs 24.

> And I pointed out that you couldn't actually infer the switch to the new interface from the doc string of `gdb'.

There's no requirement to infer the switch, because I just told about
the switch myself.

> 1. The user doesn't care about how Emacs GDB and the underlying gdb communicate, and how that changes between Emacs versions - nor should they have to care.

Users who don't care shouldn't override the Emacs defaults with an
explicit GDB command line that is based on intimate details of how GUD
invokes GDB.

Re: Gdb in emacs 24

[David Reitter]

On Oct 6, 2011, at 2:07 PM, Eli Zaretskii wrote:
>> And I pointed out that you couldn't actually infer the switch to the new interface from the doc string of `gdb'.
> 
> There's no requirement to infer the switch, because I just told about
> the switch myself.

I get it.  The random user won't (from the filename, or the doc string as it was).

>> 1. The user doesn't care about how Emacs GDB and the underlying gdb communicate, and how that changes between Emacs versions - nor should they have to care.
> 
> Users who don't care shouldn't override the Emacs defaults with an
> explicit GDB command line that is based on intimate details of how GUD
> invokes GDB.

Alright, now I understand where the confusion is coming from.

For me the default wasn't what showed up (and, in my minibuffer history, which is persistent for me, I chose "--annotate <exec-name>").
Started with -Q, I get the correct default.  If the user doesn't have to figure out the right command line arguments for gdb, I think the current solution will work.

Re: Gdb in emacs 24

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > And I pointed out that you couldn't actually infer the switch to the new interface from the doc string of `gdb'.
 > 
 > There's no requirement to infer the switch, because I just told about
 > the switch myself.

C'mon, Eli.  The need to *infer* the switch was before you posted.
The user would have needed a time machine to read your post before she
asked her question.  The docstring sucked (apparently it's been fixed)
and your reference to "gdb-mi.el" means nothing to somebody not
familiar with the intimate details.  It wouldn't have subtracted any
useful information if you had avoided referring to gdb-mi.el entirely.

 > > 1. The user doesn't care about how Emacs GDB and the underlying
 > >    gdb communicate, and how that changes between Emacs versions -
 > >    nor should they have to care.
 > 
 > Users who don't care shouldn't override the Emacs defaults with an
 > explicit GDB command line that is based on intimate details of how GUD
 > invokes GDB.

Be a little more gracious!  In case you hadn't noticed, this is the
free software movement, and users are expected and encouraged to share
tips and tricks in configuring the software they use.  That doesn't
necessarily mean they will be able to share the full understanding
necessary to come up with the tip or trick in the first place -- and
normally (ie, with software that doesn't change interfaces) it's not
necessary to fully understand.

The GDB interface change is a special case; AFAICS it really was a
good idea.  But such changes involve collateral damage, and the only
thing you can really do is apologize for it, and be especially careful
to document the risks fully.

Re: Gdb in emacs 24

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: David Reitter <david.reitter@gmail.com>,
>     emacs-devel@gnu.org
> Date: Fri, 07 Oct 2011 05:07:42 +0900
> 
> Eli Zaretskii writes:
> 
>  > > And I pointed out that you couldn't actually infer the switch to the new interface from the doc string of `gdb'.
>  > 
>  > There's no requirement to infer the switch, because I just told about
>  > the switch myself.
> 
> C'mon, Eli.  The need to *infer* the switch was before you posted.
> The user would have needed a time machine to read your post before she
> asked her question.

Are you sure we are talking about the same exchange?

I was talking about this question:

  https://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00229.html

and my response:

  https://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00231.html

which explained why the code by the OP stopped working, and suggested
a way to find a solution.  So what "time machine" are you talking
about?

All the rest, including the reference to GDB/MI and the doc string was
just additional info, that could hopefully let the OP learn something
in addition to fixing her Lisp.

>  > > 1. The user doesn't care about how Emacs GDB and the underlying
>  > >    gdb communicate, and how that changes between Emacs versions -
>  > >    nor should they have to care.
>  > 
>  > Users who don't care shouldn't override the Emacs defaults with an
>  > explicit GDB command line that is based on intimate details of how GUD
>  > invokes GDB.
> 
> Be a little more gracious!  In case you hadn't noticed, this is the
> free software movement, and users are expected and encouraged to share
> tips and tricks in configuring the software they use.  That doesn't
> necessarily mean they will be able to share the full understanding
> necessary to come up with the tip or trick in the first place -- and
> normally (ie, with software that doesn't change interfaces) it's not
> necessary to fully understand.
> 
> The GDB interface change is a special case; AFAICS it really was a
> good idea.  But such changes involve collateral damage, and the only
> thing you can really do is apologize for it, and be especially careful
> to document the risks fully.

You so completely misunderstood what I wrote that I don't even know
where to begin.  Perhaps re-read what I wrote.  Or don't.  Time to end
this silly thread.

Re: Gdb in emacs 24

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Are you sure we are talking about the same exchange?

Yes.  If this were a conversation among Emacs developers all working
on the issue directly, your responses would make sense.  In the
context of user vs. Emacs developer (the current context), they don't.
(Eg, David was clearly confused by them.)  The user is expressing
requirements, you're talking (in some sense) about the implementation.

 > You so completely misunderstood what I wrote that I don't even know
 > where to begin.

Precisely.  Here, I'm not trying to express understanding of what you
wrote (which by the way, *I* had no trouble whatsoever doing).  I'm
giving an account of what I think the user would understand from it,
based not only on my own assessment but on David's responses.

 > Perhaps re-read what I wrote.  Or don't.  Time to end this silly
 > thread.

*sigh*  I should know better than to try.

Re: Gdb in emacs 24

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 07 Oct 2011 15:08:38 +0900
> Cc: david.reitter@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii writes:
> 
>  > Are you sure we are talking about the same exchange?
> 
> Yes.  If this were a conversation among Emacs developers all working
> on the issue directly, your responses would make sense.  In the
> context of user vs. Emacs developer (the current context), they don't.
> (Eg, David was clearly confused by them.)  The user is expressing
> requirements, you're talking (in some sense) about the implementation.

I was talking about the implementation to make the advice more easily
understandable.  If something that worked in previous Emacs stopped
working, the explanation must touch at least some of what's under the
hood.  I see nothing unreasonable here.

Anyway, I cannot see any reasons except extreme boredom that could
have driven you to comment on something I said half a year ago.  What
purpose could this possibly serve, except taking an opportunity to
kick old Eli in the butt one more time?

If you really cared about that user's plight, you should have chimed
in back then and improve on my failed attempt to help her.

> Precisely.  Here, I'm not trying to express understanding of what you
> wrote (which by the way, *I* had no trouble whatsoever doing).  I'm
> giving an account of what I think the user would understand from it,
> based not only on my own assessment but on David's responses.

IOW, you are trying to educate this old fart.  I'm afraid it's too
late, so do give up.  Instead, if you think I'm doing disservice by my
responses, chime in and do it The Right Way right there and then.

Re: Gdb in emacs 24

[Stefan Monnier]

> 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?

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


        Stefan

Re: Gdb in emacs 24

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> 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.

Tom

Re: Gdb in emacs 24

[Lluís]

Tom Tromey writes:

>>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> 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

Re: Gdb in emacs 24

[Tom Tromey]

>>>>> "Lluís" == Lluís  <xscript@gmx.net> writes:

Lluís> * interpreter-exec mi <command>

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

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

I think the drawback is that you don't get MI notifications for commands
entered by the user.

What I mean by notifications is, e.g., if the user types "break main",
the current gdb will inform the MI consumer:

    &"break main\n"
    ~"Breakpoint 1 at 0x485fb3: file ../../archer/gdb/gdb.c, line 30.\n"
    =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000485fb3",func="main",file="../../archer/gdb/gdb.c",fullname="/home/tromey/gnu/archer/archer/gdb/gdb.c",line="30",times="0",original-location="main"}
    ^done

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

Yeah, that will just fail.  There's no reason to use the TUI and Emacs
at the same time, it doesn't make sense.  Maybe we could disable the TUI
if $EMACS is set.

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

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

I think you'd have to use interpreter-exec to get the notification
behavior.

So, maybe this can all be done with no changes on the gdb side.  Worth a
try.

Tom

Re: Gdb in emacs 24

[Lluís]

Tom Tromey writes:

>>>>>> "Lluís" == Lluís  <xscript@gmx.net> writes:
Lluís> * interpreter-exec mi <command>

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

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

> I think the drawback is that you don't get MI notifications for commands
> entered by the user.

> What I mean by notifications is, e.g., if the user types "break main",
> the current gdb will inform the MI consumer:

>     &"break main\n"
>     ~"Breakpoint 1 at 0x485fb3: file ../../archer/gdb/gdb.c, line 30.\n"
>     =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000485fb3",func="main",file="../../archer/gdb/gdb.c",fullname="/home/tromey/gnu/archer/archer/gdb/gdb.c",line="30",times="0",original-location="main"}
>     ^done

Well, there are two command sources:

* emacs
* user

And your comments cleared up my question about how to treat user commands.

The first will always use MI by design, the latter will (by default) use the
current interpreter.

My point is to either:

* Always force the current interpreter to MI. This can be done by transparently
  appending "-i=mi" to the cmdline arguments when starting gdb, as the "-i"
  argument is idempotent and the last one will always prevail.

* Capture user commands and wrap them through "interpreter-exec mi <command>"

I think the former is just simpler and cleaner.


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

Re: Gdb in emacs 24

[Stefan Monnier]

> 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.

How 'bout some way to just check whether `mi' is the
current interpreter.  It doesn't have to be a dedicated command, just
a command which will reliably behave differently (e.g. return some
recognizable value if `mi' is used, and return an error if not).

That would at least let us provide a clear error message to the user.

>   create a new command (e.g., "set interpreter") to set the current
>   interpreter

This is ambiguous if there's an `interpreter' variable in the currently
debugged program.  But, yes, such a command would be very welcome,
especially if it fails reliably in GDB versions that don't support it.

>   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.

At least for commands typed interactively by the user, that's true.
Don't know how many commands are sent by gdb-mi.el so I don't know if
the impact could be noticeable there, but I expect it shouldn't be
a problem.
OTOH I wonder if macros defined for example in .gdbinit would go through
`mi' or not.

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

If we can test for `mi', we can signal a clear error message to the user.

>   This can be worked around by silently appending any other interface
>   option in the cmdline when starting gdb.

No.  The whole reason why "--i=mi" and "--annotate=3" is explicitly
present in the minibuffer prompt is because adding those options
silently makes it impossible to use GUD with setups where gdb
is run indirectly (e.g. the command might be "make debug" rather than
"gdb prog", so silently adding "--i=mi" is not an option).

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

gdb-mi.el wants those commands to go through `mi' as well.


        Stefan

Re: Gdb in emacs 24

[Tom Tromey]

Stefan> How 'bout some way to just check whether `mi' is the
Stefan> current interpreter.  It doesn't have to be a dedicated command, just
Stefan> a command which will reliably behave differently (e.g. return some
Stefan> recognizable value if `mi' is used, and return an error if not).

Pretty much any MI command will do that, e.g., "-list-features".

Tom

Re: Gdb in emacs 24

[Stefan Monnier]

Stefan> How 'bout some way to just check whether `mi' is the
Stefan> current interpreter.  It doesn't have to be a dedicated command, just
Stefan> a command which will reliably behave differently (e.g. return some
Stefan> recognizable value if `mi' is used, and return an error if not).

> Pretty much any MI command will do that, e.g., "-list-features".

Then could someone patch gdb-mi.el to use this as a test and send
a clear error message to the user about the need for "-i=mi"?
I think it's too late to use "interpreter exec" for 24.1, but such
a test would at least address some of the bug reports I've seen where
users had used "--annotate=3".


        Stefan

Re: Gdb in emacs 24

[Lluís]

Stefan Monnier writes:

Stefan> How 'bout some way to just check whether `mi' is the
Stefan> current interpreter.  It doesn't have to be a dedicated command, just
Stefan> a command which will reliably behave differently (e.g. return some
Stefan> recognizable value if `mi' is used, and return an error if not).

>> Pretty much any MI command will do that, e.g., "-list-features".

> Then could someone patch gdb-mi.el to use this as a test and send
> a clear error message to the user about the need for "-i=mi"?
> I think it's too late to use "interpreter exec" for 24.1, but such
> a test would at least address some of the bug reports I've seen where
> users had used "--annotate=3".

As I said, if the use of annotate is the only problem, it can be disabled with a
simple gdb command just after gdb-mi.el starts gdb:

        set annotate 0

This trivial change should address all the bugs you referred to.

The use of "interpreter-exec" is just to make sure commands go through MI even
if the user omits the "-i=mi" argument.

Then the check you say is just to cover the case of the user starting gdb with
"-i=tui", which will probably never happen.


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

Re: Gdb in emacs 24

[Stefan Monnier]

>>> Pretty much any MI command will do that, e.g., "-list-features".
>> Then could someone patch gdb-mi.el to use this as a test and send
>> a clear error message to the user about the need for "-i=mi"?
>> I think it's too late to use "interpreter exec" for 24.1, but such
>> a test would at least address some of the bug reports I've seen where
>> users had used "--annotate=3".
> As I said, if the use of annotate is the only problem, it can be disabled with a
> simple gdb command just after gdb-mi.el starts gdb:

>         set annotate 0

> This trivial change should address all the bugs you referred to.

I don't think so: those users had "--annotate=3" *instead* of "-i=mi",
so setting annotation to 0 would probably not help much, since M-x gdb
would still hang, waiting for the MI-style answers which gdb wouldn't give.

> Then the check you say is just to cover the case of the user starting gdb with
> "-i=tui", which will probably never happen.

No it's also to cover the case where "-i=mi" is missing.


        Stefan

Re: Gdb in emacs 24

[Lluís]

Stefan Monnier writes:

>>>> Pretty much any MI command will do that, e.g., "-list-features".
>>> Then could someone patch gdb-mi.el to use this as a test and send
>>> a clear error message to the user about the need for "-i=mi"?
>>> I think it's too late to use "interpreter exec" for 24.1, but such
>>> a test would at least address some of the bug reports I've seen where
>>> users had used "--annotate=3".
>> As I said, if the use of annotate is the only problem, it can be disabled with a
>> simple gdb command just after gdb-mi.el starts gdb:

>> set annotate 0

>> This trivial change should address all the bugs you referred to.

> I don't think so: those users had "--annotate=3" *instead* of "-i=mi",
> so setting annotation to 0 would probably not help much, since M-x gdb
> would still hang, waiting for the MI-style answers which gdb wouldn't give.

>> Then the check you say is just to cover the case of the user starting gdb with
>> "-i=tui", which will probably never happen.

> No it's also to cover the case where "-i=mi" is missing.

Right, both were assuming the use of the "interpreter-exec" command.

I've been looking into it, and just starting gdb should be enough to know if
we're under GDB/MI. The possible cases I've looked into are:

* console
* console + annotate
* mi
* tui

GDB/MI gives us a unique greeting format:

    =thread-group-added,id="i1"
    ~"GNU gdb (GDB) 7.3-debian\n"
    ....
    (gdb)

What I've done is use a new gud marker filter during initialization
(gud-common-init) to establish whether the correct interpreter is being
used. After that check, the original filter (gud-gdbmi-marker-filter) is used.

The problem is that my poor elisp knowledge isn't enough to find a way to
communicate the result back into the main emacs process (as the filter seems to
be running on a separate process, I'm unable to simply set a variable to tell
whether the test is ok).

Any hints on how to communicate the result back to the 'gdb' function?


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

Re: Gdb in emacs 24

[Stefan Monnier]

> Right, both were assuming the use of the "interpreter-exec" command.

Makes sense.  But as I said, I think for 24.1, it's too late to make
this change.

> I've been looking into it, and just starting gdb should be enough to know if
> we're under GDB/MI. The possible cases I've looked into are:

> * console
> * console + annotate
> * mi
> * tui

> GDB/MI gives us a unique greeting format:

>     =thread-group-added,id="i1"
>     ~"GNU gdb (GDB) 7.3-debian\n"
>     ....
>     (gdb)

> What I've done is use a new gud marker filter during initialization
> (gud-common-init) to establish whether the correct interpreter is being
> used. After that check, the original filter (gud-gdbmi-marker-filter) is used.

Sounds great.  It could even be used to automatically fall back on the
gud-gdb code if the user used --fullname.

> The problem is that my poor elisp knowledge isn't enough to find a way to
> communicate the result back into the main emacs process (as the filter seems to
> be running on a separate process, I'm unable to simply set a variable to tell
> whether the test is ok).
> Any hints on how to communicate the result back to the 'gdb' function?

You have access to the process object, so you can change the
process-filter, or you can set a process property (via process-put).


        Stefan

Re: Gdb in emacs 24

[Lluís]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Stefan Monnier writes:

>> Right, both were assuming the use of the "interpreter-exec" command.
> Makes sense.  But as I said, I think for 24.1, it's too late to make
> this change.

Sure.

I've attached a series of patches to:

* Check if we are using a supported gdb interpreter

* Disable gdb annotations

* gdb >= 7 should be considered recent
  
  In addition, command "maint set linux-async on" does not exist.


Feel free to change the code, as I don't know if my approach is the cleanliest
way of doing it.


Lluis


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 00-check-mi.patch --]
[-- Type: text/x-patch, Size: 2251 bytes --]

=== modified file 'lisp/progmodes/gdb-mi.el'
--- lisp/progmodes/gdb-mi.el	2011-10-06 16:11:38 +0000
+++ lisp/progmodes/gdb-mi.el	2011-10-23 19:30:03 +0000
@@ -599,6 +599,29 @@
     (concat (gdb-gud-context-command ,cmd1 ,noall) " " ,cmd2)
     ,(when (not noarg) 'arg)))
 
+(defun gdb--interpreter-ok ()
+  "Whether the expected interpreter is being used.
+-1: Not checked.
+ 0: Incorrect interpreter.
+ 1: Correct interpreter."
+  (let* ((buffer gud-comint-buffer)
+         (process (get-buffer-process buffer))
+         (res (process-get process 'gdb--interpreter-ok)))
+    (if (equal res nil) -1 res)))
+
+(defun gdb--interpreter-check (string)
+  "Initial filter to check if a correct interpreter is being used."
+  (when (= (gdb--interpreter-ok) -1)
+    (let* ((target "=thread-group-added") ; first line in GDB/MI
+           (buffer gud-comint-buffer)
+           (process (get-buffer-process buffer)))
+      (if (or (> (length target) (length string))
+             (string= (substring string 0 (length target)) target))
+          (process-put process 'gdb--interpreter-ok 1)
+        (process-put process 'gdb--interpreter-ok 0))))
+  (when (= (gdb--interpreter-ok) 1)
+    (gud-gdbmi-marker-filter string)))
+
 ;;;###autoload
 (defun gdb (command-line)
   "Run gdb on program FILE in buffer *gud-FILE*.
@@ -663,8 +686,18 @@
     (gdb-restore-windows)
     (error
      "Multiple debugging requires restarting in text command mode"))
-  ;;
-  (gud-common-init command-line nil 'gud-gdbmi-marker-filter)
+
+  ;; Start gdb and check for the interpreter being used
+  (gud-common-init command-line nil 'gdb--interpreter-check)
+  (while (= (gdb--interpreter-ok) -1)   ; must wait until established
+    (sleep-for 1))
+  (unless (= (gdb--interpreter-ok) 1)
+    (setq-default gud-marker-filter 'gud-gdbmi-marker-filter)
+    (insert "\nerror: You must start gdb with the GDB/MI interface (i.e., \"gdb -i=mi\")\n")
+    (error "You must start gdb with the GDB/MI interface (i.e., \"gdb -i=mi\")"))
+  ;; Change to "standard" filter
+  (setq gud-marker-filter 'gud-gdbmi-marker-filter)
+
   (set (make-local-variable 'gud-minor-mode) 'gdbmi)
   (setq comint-input-sender 'gdb-send)
   (when (ring-empty-p comint-input-ring) ; cf shell-mode


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 01-unannotate.patch --]
[-- Type: text/x-patch, Size: 476 bytes --]

=== modified file 'lisp/progmodes/gdb-mi.el'
--- lisp/progmodes/gdb-mi.el	2011-10-23 19:30:03 +0000
+++ lisp/progmodes/gdb-mi.el	2011-10-23 19:33:06 +0000
@@ -698,6 +698,9 @@
   ;; Change to "standard" filter
   (setq gud-marker-filter 'gud-gdbmi-marker-filter)
 
+  ;; Disable annotations
+  (gud-call "set annotate 0")
+
   (set (make-local-variable 'gud-minor-mode) 'gdbmi)
   (setq comint-input-sender 'gdb-send)
   (when (ring-empty-p comint-input-ring) ; cf shell-mode


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 02-todos.patch --]
[-- Type: text/x-patch, Size: 736 bytes --]

=== modified file 'lisp/progmodes/gdb-mi.el'
--- lisp/progmodes/gdb-mi.el	2011-10-06 16:11:38 +0000
+++ lisp/progmodes/gdb-mi.el	2011-10-20 12:49:18 +0000
@@ -50,12 +50,6 @@
 ;; without gdb-ui.el and uses MI tokens instead of queues. Eventually MI
 ;; should be asynchronous.
 
-;; This mode will PARTLY WORK WITH RECENT GDB RELEASES (status in modeline
-;; doesn't update properly when execution commands are issued from GUD buffer)
-;; and WORKS BEST when GDB runs asynchronously: maint set linux-async on.
-;;
-;; You need development version of GDB 7.0 for the thread buffer to work.
-
 ;; This file replaces gdb-ui.el and is for development with GDB.  Use the
 ;; release branch of Emacs 22 for the latest version of gdb-ui.el.
 


[-- Attachment #5: Type: text/plain, Size: 218 bytes --]


-- 
 "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

Re: Gdb in emacs 24

[Stefan Monnier]

> I've attached a series of patches to:

Thanks.  I've installed a slightly different patch instead.

> * Check if we are using a supported gdb interpreter

The style wasn't very Lispish, and more importantly it was simpler to do
it by changing the process filter rather than gud-marker-filter.

> * Disable gdb annotations

I haven't installed this part, not sure that it matters.

> * gdb >= 7 should be considered recent

I've removed some obsolete text from the commentary.


        Stefan

Re: Gdb in emacs 24

[Lluís]

Stefan Monnier writes:

>> 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.

> How 'bout some way to just check whether `mi' is the
> current interpreter.  It doesn't have to be a dedicated command, just
> a command which will reliably behave differently (e.g. return some
> recognizable value if `mi' is used, and return an error if not).

> That would at least let us provide a clear error message to the user.
[...]
>> This can be worked around by silently appending any other interface
>> option in the cmdline when starting gdb.

> No.  The whole reason why "--i=mi" and "--annotate=3" is explicitly
> present in the minibuffer prompt is because adding those options
> silently makes it impossible to use GUD with setups where gdb
> is run indirectly (e.g. the command might be "make debug" rather than
> "gdb prog", so silently adding "--i=mi" is not an option).

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

> gdb-mi.el wants those commands to go through `mi' as well.

Aha, I see. Then I think the safest way to go is using "interpreter-exec" on
every command. This will work regardless of the interpreter, so there is no need
to pass "-i=mi" in the command line.

Then, as I said, annotations can be silently disabled once gdb has started ("set
annotations 0").

Finally, we're simply left with the need to check if the user is starting gdb
with the tui interpreter. For this, issuing "interpreter-exec mi help" will do
as the tui interpreter does not support "interpreter-exec".


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

Re: Gdb in emacs 24

[Andreas Schwab]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> I'm using now emacs from the trunk (in the signature the full version)
> and it works wonderfully for everything.  The only thing that doesn't
> work is the gdb.
>
> I have an elisp function to call GDB (just a shortcut):
>
> (defun gdb-pad ()
>   "Debug the simulation"
>   (interactive)
>   (gdb "gdb -cd=/long/path --annotate=3 --args /long/path/opp_run args"))

Try using gud-gdb instead.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."