Re: gud-tooltip-mode: gdb-prompt: Wrong number of arguments

[Nick Roberts]

 > Not sure what you mean with old behaviour. 

"gdb --fullname" which is what Emacs 21 (and earlier) uses, although the
fullname option was never visible in the command in the minibuffer.

 >                                             Should I see a difference (as
 > long I don't set gdb-many-windows) between "M-x gdb" and "M-x gdba". Both
 > start by printing "gdb -annotate=3 <image-name>" and then give me a gdb and
 > a source window.

The only difference is at startup.  'M-x gdba' presupposes "-annotate=3" and
is therefore ready for the "source" annotation that you see, whereas 'M-x gdb'
has to look at the markup output to work out whether gdb has been invoked
with "-annotate=3" or "-fullname" and gets caught out because "source" is
not usually the first annotation.  I'm sure the code could be further hacked
to deal with this case but I don't think the benefits justify the risks at
this point in the development cycle.

 > Isn't that confusing for the user when "gdb -annotate=3 <image-name> core"
 > works in one case, but not the other?

M-x gdb works with "-fullname" and, in almost all cases, with "-annotate=3".
M-x gdba doesn't work with "-fullname", but in all cases with "-annotate=3".

Are you suggesting that I remove one so that the user isn't confused?

 > BTW when I strip "source " from the filename by adding:
 >   (if (and file (string-match "^source " file))
 >       (setq file (replace-match "" t t file)))
 > to the beginning gud-find-file, I can call gdb the usual way, i.e. with
 > <image> and core like I would do in the shell.

You can use that as a local patch, if you like, but I don't want to install
such a hack.  What happens if the file is called 
"source filenames can have spaces.c" for example?

 > I also have serious performance issues with the new gdb interface, e.g.
 >  gdb --fullname <image-name> core
 > and then "up" or "bt" in gdb takes a bit more than 20 seconds, whereas
 >  gdba -annotate=3 <image-name> core
 > and then "up" or "bt" needs 2 and a half minutes.

Yes, the new interface is too inefficient at times.  Its an ongoing process,
but after the release (we're already two years nearer than we were two
years ago), things should get better when we move from annotations to GDB/MI.

 > This is almost certainly not an emacs problem, but seems to be caused by
 > the --annotate=3 option for gdb and of course our image size (125 MB and
 > 155 for the core file).

Well it's caused by the way Emacs uses the annotations.  Maybe it could be
done better, but its the best that I could do.  For such a large image and
core you're probably better off using "gdb -fullname".

 > Does "--annotate" even make sense when analyzing a core?

Well you can't step through the program or set breakpoints, but if you want to
see the stack, the locals, examine memory... certainly it does.

-- 
Nick                                           http://www.inet.net.nz/~nickrob