gdb modes try to insert breakpoint markers too soon

gdb modes try to insert breakpoint markers too soon

[Bruce Stephens]

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

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.

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

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

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.  

When I hit the breakpoint, gdb produces two messages:

Breakpoint 2, explode (bind_arg=0xb719c5c0) at explode.c:241

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

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

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

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

Re: gdb modes try to insert breakpoint markers too soon

[Bruce Stephens]

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

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

6.3-debian.

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

No, I mean either of them (i.e., one at a time).

In any case, the rest isn't so important.  I was running emacs21.3.50,
so the gdb-ui.el was a little old.  Now that I've cleaned things up so
I'm running emacs22.0.50 (from Miles's Arch repository, from which
it's kind of awkward to get CVS versions, but gdb-ui.el seems to be
1.47), things work as I expect.

That is, I don't see a problem with the current code.

[...]