gdb modes try to insert breakpoint markers too soon

[Nick Roberts]

 > There seems to be an irritating interaction between gdb and the gdb
 > modes in current CVS Emacs (gdb and gdba).

What version of gdb are you using?

Do you mean the you have two sessions running concurrently, one started
with M-x gdb and the other M-x gdba?

Note that the default for M-x gdb is now --annotate=3, so that they both
run the same mode. This mode only supports one session at a time and
if you start both with M-x gdb you get an error message. I will change
gdb-ui.el so that this happens for the above case too.

 > When I set a breakpoint, gdb prints out something like this:
 > 
 > (gdb) break explode
 > Breakpoint 2 at 0xb7ce73e2: file explode.c, line 241.
 > 
 > and much the same with --annotate=3 and GDB/MI.  i.e., it seems not to
 > give the full pathname.

That is normal command line output from gdb. Nothing appears to be wrong
there. GDB/MI is a separate interface to annotations and is not currently
used as the primary interface by Emacs in CVS.

 > My executable and its libraries are compiled with DWARF2 debugging
 > information, and readelf shows that all of the directories are known.

GDB knows the directories, it just doesn't print them out.

 > When execution hits the breakpoint, gdb displays the full pathname.

This is probably the annotation output that the user is not meant to see.

 > So when running under Emacs, on setting the breakpoint, Emacs creates
 > an empty buffer "explode.c" in the directory in which the executable
 > was linked.  

Is this with the most recent changes to gdb-ui.el (CVS version 1.48)?

 > When I hit the breakpoint, gdb produces two messages:
 > 
 > Breakpoint 2, explode (bind_arg=0xb719c5c0) at explode.c:241

Normal output.

 > source 
 > /local/brs/top-test/build/isode/src/lib/explode.c:241:6202:beg:0xb7ce73e2

Annotation output that the user is not meant to see.

 > (or whatever).  So again Emacs tries to find explode.c in its search
 > path, and is then told exactly where it is.
 > 
 > What's the best way of dealing with this?  (I suppose disabling
 > auto-insert would make this less annoying.)

Finding out why the errors occur rather than trying to handle them.

 > (Creating a .gdbinit file with lots of "directory" commands mostly
 > works, but unfortunately I have files with identical names (generally
 > a bad idea, but in this case justified, I think).  In any case, that
 > seems silly: the information's available; DDD copes without apparent
 > difficulty.)

.gdbinit isn't the place the correct the above problems.


Nick