This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Attachment: mi-more-stack.diff
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, wrote:

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, and I
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).


Jim Ingham
Developer Tools - gdb

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]