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

[Bob Rossi <bob@brasko.net>]

> >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