Using gdb with emacs

Using gdb with emacs

[Tom Tromey]

I've found a debugging problem that spans both Emacs and gdb.  From
what I understand of the problem it has both a gdb component and an
Emacs component; hence the CC.  (gdb folks, please bear with me; your
part is at the end.)

I'm using GNU Emacs 20.5.1, and the current CVS (trunk) gdb.

I'm debugging libgcj using Mauve, a free software Java test suite.
Mauve is structured as a bunch of directories named after Java
classes; for instance tests for java.lang.String would appear in the
directory gnu/testlet/java/lang/String/.  Mauve has a fairly large
number of files with the same names; for instance `Test.java' appears
in many directories.

When I build Mauve, I make a parallel build tree and build it there
(i.e., I don't build in the source tree).

Now suppose I debug SimpleTestHarness (the basic Mauve program) using
gud mode in Emacs.  Say I'm debugging the DateFormat implementation.
The file I want to put a breakpoint in is:

    mauve/gnu/testlet/java/text/DateFormat/Test.java

I open a buffer on this file, move point to the line I want, and type
C-x SPC (aka gud-break).  In the *gud* buffer I see this:

    Breakpoint 1 at 0x80afc2d: file ../mauve/gnu/testlet/java/io/ObjectInputOutput/Test.java, line 83.

This is clearly wrong.  If I ask gdb it tells me what happened:

    (gdb) show commands
	1  break Test.java:83

Emacs stripped the directory information, and gdb simply chose some
random Test.java file (and, btw, let me note that the first few times
this happens, you don't notice, and you have a very frustrating
debugging experience).

If you look in gud.el, you can easily the code:

  (gud-def gud-break  "break %f:%l"  "\C-b" "Set breakpoint at current line.")

I think it would make sense to change this line to something like
this, at least if using gdb on a Unix-like platform:

  (gud-def gud-break  "break %d/%f:%l"  "\C-b" "Set breakpoint at current line.")

(Perhaps it would be better to introduce a new % substitution that
does not strip directory information.)


Unfortunately -- and this is where gdb enters the picture -- that
change won't work.  Suppose I mimic the above change by typing in the
resulting command:

    (gdb) break /home/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/Test.java:83
    No source file named /home/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/Test.java.


The correct invocation, from gdb's point of view, is this:

    (gdb) break ../mauve/gnu/testlet/java/text/DateFormat/Test.java:83
    Breakpoint 2 at 0x8092c41: file ../mauve/gnu/testlet/java/text/DateFormat/Test.java, line 83.

That leading `..' appears because of the way I built Mauve.
Unfortunately, there's no way for Emacs to guess that that is what is
required.

I suppose one workaround would be to always run configure with an
absolute path.  That would probably work in most situations.  I'd
prefer not to have to do that.  I'm long past used to using relative
paths here.

I think it would be reasonable for gdb to do path canonicalization on
file names.  I think that would let the proposed Emacs change work
correctly.

Tom

Re: Using gdb with emacs

[Per Bothner]

Tom Tromey <tromey@redhat.com> writes:

> I think it would be reasonable for gdb to do path canonicalization on
> file names.  I think that would let the proposed Emacs change work
> correctly.

The way it used to be was that Gcc would emit two top-level filename
stabs: One for the filename as specified on the command line, and one
for the current working directory.  That lets gdb match the intended
file somewhat intelligently.  It is possible this is broken, in
either gcc or gdb.  Its is also possible that this logic may be
unsupported for some debugging formats.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Using gdb with emacs

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 06 Sep 2001 19:34:49 -0600
> 
> If you look in gud.el, you can easily the code:
> 
>   (gud-def gud-break  "break %f:%l"  "\C-b" "Set breakpoint at current line.")
[...]
>     (gdb) break /home/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/Test.java:83
>     No source file named /home/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/Test.java.
> 
> The correct invocation, from gdb's point of view, is this:
> 
>     (gdb) break ../mauve/gnu/testlet/java/text/DateFormat/Test.java:83
>     Breakpoint 2 at 0x8092c41: file ../mauve/gnu/testlet/java/text/DateFormat/Test.java, line 83.
> 
> That leading `..' appears because of the way I built Mauve.

What happens if you do this:

     (gdb) dir /home/tromey/gnu/egcs/mauve/gnu/testlet/java/text/DateFormat
     (gdb) break Test.java:83

Does it work then?

See, I think GUD was written with this setup in mind: it assumes that
the directory of the files is known and is in the list searched by GDB
for sources.  That's why I think you have only %f in the gud-def you
mentioned above.

In fact, GDB itself also assumes something like that: for every object
module which states its source file name, GDB remembers both the
basename and the file name as recorded in the debug info.  That is
why, given the current buffer's default directory is where you ran GCC
to compile Test.java, you can say both "break Test.java:83" and "break
../mauve/gnu/testlet/java/text/DateFormat/Test.java:83".

So I think we need at to least consider another possibility: set
things up so that all your directories are passed to GDB's dir
command, and then using the basename in the break commands should
work.  Anything else will IMHO be much more complex and, as Per quite
correctly pointed out, non-portable because different debug info
formats record file names in different forms; you just looked at one
particular type of debug info.  Some types of debug info don't even
record the leading directories.

(In general, I think using the file names with leading directories in
GDB is a bad idea, because they depend too much on the assumption that
you debug in the same place where you compiled them.  Move the build
tree and you are toast.)

> I suppose one workaround would be to always run configure with an
> absolute path.  That would probably work in most situations.

Yes, but only for the kind of debug info which records the absolute
file name.

> I'd prefer not to have to do that.  I'm long past used to using
> relative paths here.

Alternatively, you could use local file variables to set
default-directory of Test.java to the directory where you run the
compiler.  This is ugly, though, and its side effects will probably
surprise you at some point.

Re: Using gdb with emacs

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> What happens if you do this:
Eli>      (gdb) dir /home/tromey/gnu/egcs/mauve/gnu/testlet/java/text/DateFormat
Eli>      (gdb) break Test.java:83
Eli> Does it work then?

Yes, that will work for this particular case.  But I don't think it
solves the general problem.  In Mauve, all these files are compiled
(with gcj) into a single executable.  Mauve has 121 directories.  And
it has 20 files named "Test.java".

Eli> So I think we need at to least consider another possibility: set
Eli> things up so that all your directories are passed to GDB's dir
Eli> command, and then using the basename in the break commands should
Eli> work.

First, running 121 `dir' commands seems excessive.  Second, if I run
all those `dir' commands, gdb still won't know which Test.java I mean.
How could it?

One idea would be for Emacs itself to send the `dir' command to gdb
before issuing the breakpoint.  Maybe that would work ok.  Is that
what you are suggesting?  I would classify this as a potential
workaround, but not really a fix.

Eli> Anything else will IMHO be much more complex and, as Per quite
Eli> correctly pointed out, non-portable because different debug info
Eli> formats record file names in different forms; you just looked at one
Eli> particular type of debug info.  Some types of debug info don't even
Eli> record the leading directories.

I'm not particularly concerned with situations where the debug info is
not robust.  I think it is reasonable for gdb to adopt an approach of
making things work very well on robust platforms (for instance,
Linux), and then having the feature degrade gracefully on less capable
platforms.  I disagree with the idea that gdb must support only the
least common denominator.

Tom

Re: Using gdb with emacs

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> What happens if you do this:
Eli> (gdb) dir /home/tromey/gnu/egcs/mauve/gnu/testlet/java/text/DateFormat
Eli> (gdb) break Test.java:83
Eli> Does it work then?

Tom> Yes, that will work for this particular case.

I spoke too soon.  I tried it, and it does not work:

    (gdb) b Test.java:58
    Breakpoint 1 at 0x80afa20: file ../mauve/gnu/testlet/java/io/ObjectInputOutput/Test.java, line 58.
    (gdb) dir ~/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/
    Source directories searched: /x2/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat:$cdir:$cwd
    (gdb) b Test.java:58
    Note: breakpoint 1 also set at pc 0x80afa20.
    Breakpoint 2 at 0x80afa20: file ../mauve/gnu/testlet/java/io/ObjectInputOutput/Test.java, line 58.


I dug through the gdb source a bit.  The problem is that `dir' is
(apparently) only used to find the source file for listing purposes
(source.c).  It doesn't appear to be used when trying to determine
which source file a user means when he (or Emacs) types "b Test.java"
(this code is in symtab.c).

Tom

Re: Using gdb with emacs

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 07 Sep 2001 14:38:22 -0600
> 
> In Mauve, all these files are compiled
> (with gcj) into a single executable.  Mauve has 121 directories.  And
> it has 20 files named "Test.java".

Then what I suggested won't work.  (Personally, I think having many
files by the same name is not a good idea, given how GDB works with
file names recorded in the debug info.)

> First, running 121 `dir' commands seems excessive.

Not if you put that on a .gdbinit file which is part of the source
tree: the directories are known in advance.  But that is not the real
issue here, so let's not engage in nitpicking, okay?

> Second, if I run all those `dir' commands, gdb still won't know
> which Test.java I mean.  How could it?

It can't.  I didn't assume you have many files with the same
basename.

> I disagree with the idea that gdb must support only the least common
> denominator.

I didn't suggest that it should.  And GDB is not the problem, I think:
in GDB, you could simply type your original command:

   (gdb) break ../mauve/gnu/testlet/java/text/DateFormat/Test.java:85

and it would have worked, right?

The problem, if I understand it correctly, is with Emacs, specifically
because, unlike GDB, Emacs doesn't have a notion of a single ``current
directory''.  Its equivalent of the cwd changes when you switch to
another buffer.

What you, in effect, want is for GUD to support relative file names
which are not relative to the default directory of the buffer from
which you set the breakpoint.  This invalidates the assumptions on
which Emacs primitives such as expand-file-name and file-relative-name
base their default operation.  So supporting this at least requires
that GUD knows such file names are supported by the inferior GDB, and
that such file names should be used instead of just the basename.  We
need to find a way to communicate this to GUD somehow.  We also need a
way to tell GUD what is the directory which will serve as the starting
point of the relative file names; let's call this a ``project
directory''.

AFAIK, there's no easy way this information can come from GDB itself,
so we should probably burden the user with supplying it.

All this seems to suggest that just changing %f into %d/%f won't do.
I think we need:

  - A command to set the name of the project directory.

  - A modification of the set breakpoint commands whereby it will
    first try to use file names relative to the project directory if
    that directory is set, and if that fails, fall back on the
    basename, like it does today.  This probably calls for a new
    %something specifier, which will trigger this modified behavior,
    since you probably don't want to change the semantics of %f.

Re: Using gdb with emacs

[Richard Stallman]

    What you, in effect, want is for GUD to support relative file names
    which are not relative to the default directory of the buffer from
    which you set the breakpoint.  This invalidates the assumptions on
    which Emacs primitives such as expand-file-name and file-relative-name
    base their default operation.

These primitives use the value of the variable default-directory,
which Lisp code can easily bind.  So these primitives don't limit
anything.  As long as there is a clear convention for what the
default directory should be, the code in gud.el should be able
to handle it.

Re: Using gdb with emacs

[Eli Zaretskii]

> Date: Sun, 9 Sep 2001 09:03:25 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
>     What you, in effect, want is for GUD to support relative file names
>     which are not relative to the default directory of the buffer from
>     which you set the breakpoint.  This invalidates the assumptions on
>     which Emacs primitives such as expand-file-name and file-relative-name
>     base their default operation.
> 
> These primitives use the value of the variable default-directory,
> which Lisp code can easily bind.

Sure, but someone should bind default-directory.  Usually, when you
set a breakpoint from a buffer that visits a file, the natural thing
is to use that buffer's default-directory, so that's what GUD does.  I
think what Tom wants requires some way to tell GUD to do bind
default-directory, and also to tell it what directory to bind it to.

In other words, I think it's hard to expect that the existing code
could be tweaked on the user level into doing what Tom wants, but it's
not rocket science to change GUD to allow this mode.

Re: Using gdb with emacs

[Per Bothner]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>   - A modification of the set breakpoint commands whereby it will
>     first try to use file names relative to the project directory if
>     that directory is set, and if that fails, fall back on the
>     basename, like it does today.  This probably calls for a new
>     %something specifier, which will trigger this modified behavior,
>     since you probably don't want to change the semantics of %f.

The concept of a "project directory" may be useful, but it is not
appropriate for setting a breakpoint on a known file in an Emacs
window.  Emacs knows the full absolute pathname of the file you are
setting a breakpoint on.  It should pass that to gdb, period.  If I
set a breakpoint using a fully qualified absolute filename, gdb should
be able to figure out which file I mean, period.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Using gdb with emacs

[Eli Zaretskii]

> From: Per Bothner <per@bothner.com>
> Date: 09 Sep 2001 10:15:02 -0700
> 
> Emacs knows the full absolute pathname of the file you are
> setting a breakpoint on.  It should pass that to gdb, period.  If I
> set a breakpoint using a fully qualified absolute filename, gdb should
> be able to figure out which file I mean, period.

I don't see how can GDB do what you want; perhaps I'm missing
something.

The debug info recorded in the executable says that one of the source
files is ../foo/bar/baz.c.  How can GDB know that a file you are
visiting, whose absolute file name is /home/user/project/foo/bar/baz.c,
is that file?

What I suggested is to tell GUD that the project directory is
/home/user/project/build.  Armed with that knowledge, we could modify
GUD to produce a file name relative to /home/user/project/build, and
the result will allow GDB to identify that file in its data base.

Re: Using gdb with emacs

[Per Bothner]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't see how can GDB do what you want; perhaps I'm missing
> something.
> 
> The debug info recorded in the executable says that one of the source
> files is ../foo/bar/baz.c.  How can GDB know that a file you are
> visiting, whose absolute file name is /home/user/project/foo/bar/baz.c,
> is that file?

Because gcc, for each .o file (at least when using stabs) emits
*both* the relative filename *and* the current working directory.
So gdb can calculete the absolute filename.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Using gdb with emacs

[Richard Stallman]

    The debug info recorded in the executable says that one of the source
    files is ../foo/bar/baz.c.  How can GDB know that a file you are
    visiting, whose absolute file name is /home/user/project/foo/bar/baz.c,
    is that file?

If the files named baz.c have full names ../foo/bar/baz.c and
../foo/lose/baz.c, GDB could figure out that
/home/user/project/foo/bar/baz.c, must be the former rather than the
latter.  It could move up in the file names, eliminating possibilities
when it sees a mismatch, and if at some point only one file name still
remains undisqualified, that is the one.

    Because gcc, for each .o file (at least when using stabs) emits
    *both* the relative filename *and* the current working directory.
    So gdb can calculete the absolute filename.

It can do that, and that may be one good thing to try; but that may
not be the full solution.  It is not unusual to move directories
around; when that has happened, this method would fail just like now.

Perhaps it should first try to recognize the absolute file name,
and then, if that fails, try what I suggested above.

Re: Using gdb with emacs

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> It can't.  I didn't assume you have many files with the same
Eli> basename.

The problem doesn't really occur if every file has a unique name, due
to how the gdb `break' command searches for files.

Eli>    (gdb) break ../mauve/gnu/testlet/java/text/DateFormat/Test.java:85
Eli> and it would have worked, right?

Yes, that would have worked.

Eli> What you, in effect, want is for GUD to support relative file
Eli> names which are not relative to the default directory of the
Eli> buffer from which you set the breakpoint.

Actually, that isn't what I want.  I want it to work without any extra
interaction by me.  One way would be for both gdb and Emacs to agree
that using absolute paths will work.

Eli> AFAIK, there's no easy way this information can come from GDB
Eli> itself, so we should probably burden the user with supplying it.

I dislike this solution.  It means more work for me, the user, when
clearly more work isn't required -- Emacs knows the absolute path, and
gdb can (in theory) already find it via the paths specified to `dir'.

For instance, gdb already knows that
`../mauve/gnu/testlet/java/text/DateFormat/Test.java' is a file in my
program.  It gets this information, verbatim, from the debug info.

If I type `break
/blah/blah/mauve/gnu/testlet/java/text/DateFormat/Test.java:57', gdb
could very easily go down the list of directories as set by `dir', and
for each one go through each file in the executable, concatenate and
normalize, and then see if the answer is right.

For instance, if the directory list is `/one:/blah/blah, then gdb could
first try:

    /one/../mauve/gnu/testlet/java/text/DateFormat/Test.java
which normalizes to (I assume no symlinks, but gdb need not -- it
could use realpath):
    /one/mauve/gnu/testlet/java/text/DateFormat/Test.java

If that fails then gdb would try:

    /blah/blah/../mauve/gnu/testlet/java/text/DateFormat/Test.java
which normalizes to:
    /blah/blah/mauve/gnu/testlet/java/text/DateFormat/Test.java
-- the right answer.

This might be expensive, so probably it should only be done if the
argument to `break' is an absolute path.  Or maybe caching would be
appropriate.

One reason I think this is important is that even the worst IDE can
let the user do this without a lot of fuss.  I think it shouldn't be a
problem for Emacs+gdb to handle it too.

Tom

Re: Using gdb with emacs

[Andrew Cagney]

> If I type `break
> /blah/blah/mauve/gnu/testlet/java/text/DateFormat/Test.java:57', gdb
> could very easily go down the list of directories as set by `dir', and
> for each one go through each file in the executable, concatenate and
> normalize, and then see if the answer is right.


When this was last discussed with mi/dos in mind, one additional nasty 
step was suggested - posix-ise or canonicalise all paths.  perhaps the 
recent ``/'' vs ``\'' cleanup has eliminated the need to do this.
andrew

Re: Using gdb with emacs

[Eli Zaretskii]

> Date: Tue, 11 Sep 2001 11:16:00 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> When this was last discussed with mi/dos in mind, one additional nasty 
> step was suggested - posix-ise or canonicalise all paths.  perhaps the 
> recent ``/'' vs ``\'' cleanup has eliminated the need to do this.

FWIW, I don't think the DOSish file names will interfere with this
issue in any way.  If it will be decided to canonicalize all file
names stored with the symbol tables, the same can be done without
hurting the DOS/Windows ports.

Re: Using gdb with emacs

[Richard Stallman]

    Yes, that will work for this particular case.  But I don't think it
    solves the general problem.  In Mauve, all these files are compiled
    (with gcj) into a single executable.  Mauve has 121 directories.  And
    it has 20 files named "Test.java".

Is it necessary for them all to have the same name?
Could you rename these files to 20 different names?

    I'm not particularly concerned with situations where the debug info is
    not robust.  I think it is reasonable for gdb to adopt an approach of
    making things work very well on robust platforms (for instance,
    Linux),

Linux is not a platform at all, just a part of one.  Various GNU
programs such as GCC, GAS and GNU libc are at least as relevant to the
qualities of this platform for debugging as Linux is.  So please don't
lump our work in with the much smaller program, Linux.  See
http://www.gnu.org/gnu/linux-and-gnu.html for more explanation.

Re: Using gdb with emacs

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> Is it necessary for them all to have the same name?
rms> Could you rename these files to 20 different names?

Yes, I could.  And that would work around this problem.  However, I
dislike having to change my program because of bugs in the tools.

Tom

Re: Using gdb with emacs

[Richard Stallman]

    So I think we need at to least consider another possibility: set
    things up so that all your directories are passed to GDB's dir
    command, and then using the basename in the break commands should
    work.

If this is what is needed, maybe we should mention it in the
Emacs manual section on GUD.

Re: Using gdb with emacs

[Andrew Cagney]

tom, check:

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=137&database=gdb&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3Ddir%26columns%3Dcategory%26columns%3Dstate%26columns%3Dresponsible%26columns%3Dsynopsis%26cmd%3Dsubmit%2520query%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Dignoreclosed

the same problem was identified in the mi.  from memory, the theory was 
that the gui and the mi would both use full paths.  this behavour is 
very different to the cli.

it was also noted that a (gdb) path edit command, that would chop bits 
of a path off, would be needed. (say things get moved).

andrew

Re: Using gdb with emacs

[Fernando Nasser]

Andrew Cagney wrote:
> 
> (...)
> it was also noted that a (gdb) path edit command, that would chop bits
> of a path off, would be needed. (say things get moved).
> 

There was a path submission regarding a "pathmap" command that would
solve the
problem of files compiled on a different location than the one they're
installed.

Was that patch accepted and incorporated?
I am away from my machine and can't check it myself at the moment)

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Using gdb with emacs

[Christopher Faylor]

On Sat, Sep 08, 2001 at 01:45:05PM -0400, Fernando Nasser wrote:
>Andrew Cagney wrote:
>> 
>> (...)
>> it was also noted that a (gdb) path edit command, that would chop bits
>> of a path off, would be needed. (say things get moved).
>> 
>
>There was a path submission regarding a "pathmap" command that would
>solve the
>problem of files compiled on a different location than the one they're
>installed.
>
>Was that patch accepted and incorporated?
>I am away from my machine and can't check it myself at the moment)

No.  I don't believe that it was ever accepted.

cgf

pathmap patch dropped [was: Re: Using gdb with emacs]

[Jim Blandy]

Christopher Faylor <cgf@redhat.com> writes:
> >There was a path submission regarding a "pathmap" command that would
> >solve the
> >problem of files compiled on a different location than the one they're
> >installed.
> >
> >Was that patch accepted and incorporated?
> >I am away from my machine and can't check it myself at the moment)
> 
> No.  I don't believe that it was ever accepted.

Whose approval did that patch require?