-file-list-exec-source-files implementation

-file-list-exec-source-files implementation

[Bob Rossi]

Hi,

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?

Thanks,
Bob Rossi

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

[Eli Zaretskii]

> Date: Mon, 15 Dec 2003 19:10:40 -0500
> From: Bob Rossi <bob@brasko.net>
> 
> 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.

Isn't it possible that the sources are actually in a different
directory than the one recorded in the debug info, and if so, isn't it
true that GDB allows to work with sources in such a case by means of
the appropriate `dir' command?

In such a case, the first alternative is not the way to go, as it will
return unusable file names, and the way CLI does it is better, I
think.

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

[Andrew Cagney]

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

Andrew


> Bob Rossi
> 

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

[Bob Rossi]

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

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

[Kip Macy]

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

Plenty of other commands violate the grammar as specified in the
documentation, so it doesn't really matter, but technically it
should be something like:

^done,symfiles=[psymtab_file="filename", ...]



			-Kip

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

[Bob Rossi]

On Fri, Feb 06, 2004 at 06:27:45PM -0800, Kip Macy wrote:
> >
> > 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?
> 
> Plenty of other commands violate the grammar as specified in the
> documentation, so it doesn't really matter, but technically it
> should be something like:
> 
> ^done,symfiles=[psymtab_file="filename", ...]

Does anyone know if the appropriate output would be something like
below?

^done,symfiles={symfile=[{filename="foo.c",fullname="/home/.../foo.c"}],symfile=[{...}]},
psymfiles={psymfile=[{filename="bar.c",fullname="/home/.../bar.c"}]}

That groups the symfiles and the psymfiles. While grouping each
individual symfile and psymfile.

Thanks,
Bob Rossi

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

[Kip Macy]

>
> ^done,symfiles={symfile=[{filename="foo.c",fullname="/home/.../foo.c"}],symfile=[{...}]},
> psymfiles={psymfile=[{filename="bar.c",fullname="/home/.../bar.c"}]}

I can't say if this output would be "appropriate", but it is more in
line with the documented MI grammar.


			-Kip

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

[Andrew Cagney]

> ^done,symfiles={symfile=[{filename="foo.c",fullname="/home/.../foo.c"}],symfile=[{...}]},
>> psymfiles={psymfile=[{filename="bar.c",fullname="/home/.../bar.c"}]}
> 
> 
> I can't say if this output would be "appropriate", but it is more in
> line with the documented MI grammar.

It's certainly closer (yes trying to get it right is important :-).

I think it should simply be:

^done,files=[{filename="bar.c",fullname="/foo/bar.c"},...]

Since symtab and psymtab are internal implementation details they 
shouldn't be revealed by this command.

Andrew

(don't forget doco and test updates)

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

[Bob Rossi]

On Tue, Feb 10, 2004 at 04:59:45PM -0500, Andrew Cagney wrote:
> >^done,symfiles={symfile=[{filename="foo.c",fullname="/home/.../foo.c"}],symfile=[{...}]},
> >>psymfiles={psymfile=[{filename="bar.c",fullname="/home/.../bar.c"}]}
> >
> >
> >I can't say if this output would be "appropriate", but it is more in
> >line with the documented MI grammar.
> 
> It's certainly closer (yes trying to get it right is important :-).
> 
> I think it should simply be:
> 
> ^done,files=[{filename="bar.c",fullname="/foo/bar.c"},...]
> 
> Since symtab and psymtab are internal implementation details they 
> shouldn't be revealed by this command.

Ok, I like this better also, I was trying to closer mirror the 'info
sources' command.
> 
> Andrew
> 
> (don't forget doco and test updates)

No problem.

Thanks,
Bob Rossi