[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gdb modes try to insert breakpoint markers too soon
From: |
Nick Roberts |
Subject: |
gdb modes try to insert breakpoint markers too soon |
Date: |
Wed, 16 Feb 2005 09:26:02 +1300 |
> 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