This is the mail archive of the
mailing list for the GDB project.
Re: GDB/MI absolute path
- From: Jim Ingham <jingham at apple dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 7 Feb 2003 10:04:34 -0800
- Subject: Re: GDB/MI absolute path
We actually found that even when run from a GUI, you need absolute
paths for files sometimes. The reason for this is that the user may
have several projects, say one which builds a shared library, and one
an app that uses it. If debugging with the app project open, but not
the shlib project, you can end up in a frame with debug info referring
to sources you don't know about.
For our purposes, we found it sufficient to add the dir path to the
-stack-list-frames command. Pretty much the only time we would not
know where a file was was when gdb stopped, and we were fetching the
stack. You might also want it in the mi -break-insert command as well,
if you want to map from breakpoints to files in you UI, dunno...
Anyway, we did this by adding a "frame_more_info" hook to the ordinary
stack.c frame printing. We haven't needed to add anything but the
directory yet, but this does seem a place where more info might be
useful in the future, so...
Anyway, if you are interested, here is a patch against the FSF TOT.
It's hacked out of our sources - we haven't merged back from the
interpreter branch yet, so there are a lot of differences between our
sources & the FSF. But this is pretty simple, and should work.
Description: Binary data
In general, I would prefer working in two directions for this sort of
thing. First, we like to try to reduce the number of round trips
between the UI and gdb for performance reasons, so when - like this -
it is pretty obvious that a piece of info is generally useful when you
issue some command, we try to include it in the return from that
command. Second, it is nice to keep the MI simple and declarative, so
if you think there will be cases other than when you have a stack in
front of you that you will need the full path to a file, I would add
an explicit command to get this result... You have to balance these
two desires so you don't get bloated command returns, but you also
don't have to go many identical round trips for common operations.
Hope this helps,
On Friday, February 7, 2003, at 05:06 AM,
Thanks for the great answer.
On Thu, Feb 06, 2003 at 02:17:30PM -0800, Keith Seitz wrote:
On Thu, 2003-02-06 at 13:55, Bob Rossi wrote:
Also, what is the best way to ask mi for the absolute path to the
current source file. This wasn't a problem using annotate 1 or 2,
can't figure out how to get it using mi.
This is a known (to me) problem with MI. The problem is that MI was
designed to work with an IDE, not just a stand-alone GUI for the
debugger. In the case of an IDE, this information isn't needed, since
the IDE knows everything there is to know about files.
However, like Insight, cgdb will need some way of turning
"../foo/bar/baz.c" into "/home/a/b/c/foo/bar/baz.c". There are two
options (excluding hacks around the problem):
1. Get the complete source search path from GDB and let the GUI search
for the file. This means the GUI writer would also need the compile
directory for each file.
2. Get GDB to tell you where it thinks a file is located.
I would like to write a patch to GDB/MI and send it in with a bug
report. Does any of the GDB/MI maintainers know if the current design
model of GDB/MI would prefer an implicit return of the current
absolute path ( like annotations ) or an explicit return ( the GUI
requests it every time via a new GDB/MI command).
Developer Tools - gdb