Re: -file-list-exec-source-files implementation

Bob Rossi
2004-02-07T02:23:24Z

> >I am working on implementing the -file-list-exec-source-files command
> >for the MI interface. I wanted to make sure the community liked my ideas
> >before I really got into it. I looked at sources_info in symtab.c to
> >find out how to implement the MI call. The only change I think would be
> >nice over the CLI interface is if the MI command gave the fullpath along
> >with the regular path that 'info sources' currently outputs.
> >
> >I currently have come up with 3 possibilities and wonder what's best.
> >
> >1. I could make -file-list-exec-source-files always return the fullpath.
> >
> >2. I could make -file-list-exec-source-files return the fullpath of
> >each file if a parameter was passed to the function.
> >
> >The obvious question with these 2 option's is if finding the fullpath
> >for each file is to costly of an operation to put upon each user of this
> >function.
> >
> >3. The other option is to do it the way the CLI does it. It makes the user
> >do the 'info sources' to find the file of interest. And then do 'list
> >foo.c:1' and then 'info source'. After that, the CLI outputs the
> >absolute path to the file foo.c. I could make the user do
> >'-file-list-exec-source-files' to get the relative paths. Then the user
> >could do '-file-list-exec-source-file foo.c' to get the absolute path to
> >that file.
> >
> >I prefer the first alternative if it is possible to look up the fullpath
> >to all of the file's that the exe is made up of. This must be scalable
> >for even the largest executable's that GDB supports.
> >Does this sound reasonable? I don't really know how costly the operation
> >of looking up the fullpath to a file is in GDB. If it is not reasonable,
> >the third alternative will be the best way to go.
> >
> >Any suggestions?
>
> A guess is "yes". Return all of:
>
> - the short name
> - the relative name (from memory what's what is in the debug info)
> - the full name
>
> But possibly control the last one with an option. Relatively speaking,
> I don't think this is an expensive operation.
>
> I think having it modal (like you describe "info source"s current
> behavior) would just confuse things. And yes, as you and Eli note,
> having just the short name won't be much help - GDB should have and
> provide all the information needed to

Well, I have a patch, and I am ready for some suggestions.
(the patch will be posted to gdb-patches)
I provided the filename ( relative ), and the fullname (absolute) to the user.
When the fullname can not be found by GDB, it will not get written out.

Basically, I lifted some of the code from sources_info in symtab.c. It
had the functionality I was looking for. In addition, whenever a
fullname wasn't available, I attempted to look it up by using
'source_full_path_of' which is basically a wrapper around openp.

For a simple program, that output of 'info sources' appears as,

(top-gdb) info sources
Source files for which symbols have been read in:

Source files for which symbols will be read in on demand:

/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S,
/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crti.S, init.c, ../sysdeps/i386/elf/start.S,
test.c

For the new mi command, it looks like this,
-file-list-exec-source-files
^done,psymtab_file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S",psymtab_file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crti.S",psymtab_file="init.c",psymtab_fullname="/home/bob/cvs/src/src/src/gdb/init.c",psymtab_file="../sysdeps/i386/elf/start.S",psymtab_file="test.c",psymtab_fullname="/home/bob/cvs/src/src/src/gdb/test.c"

Any objections or suggestions?

Bob Rossi