GDB/MI absolute path

[Jim Ingham]

Bob,

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mi-more-stack.diff
Type: application/octet-stream
Size: 4812 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb/attachments/20030207/7eebb119/attachment.obj>
-------------- next part --------------


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,

Jim


On Friday, February 7, 2003, at 05:06  AM, 
gdb-digest-help@sources.redhat.com 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).
>
> Thanks
> Bobby
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb