[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using gdb with emacs
Re: Using gdb with emacs
Sat, 08 Sep 2001 10:34:24 +0300
> From: Tom Tromey <address@hidden>
> 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
> I disagree with the idea that gdb must support only the least common
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
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
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.