Re: [MI] -file-list-exec-source-files

[Andrew Cagney <cagney at gnu dot org>]

> On Mon, Feb 16, 2004 at 10:46:28AM -0500, Daniel Jacobowitz wrote:
>
> > On Mon, Feb 16, 2004 at 10:33:29AM -0500, Bob Rossi wrote:
>
> > > Here is the problem I am trying to solve.
> > > 
> > > Any front end needs to know the absolute path to the source files. From
> > > what I can see, there are several ways of finding the absolute path.
> > > In some cases, all of this info is needed.
>
> >
>
> > > So, basically, I am making an assumption, if GDB can not find the
> > > absolute path to the source file, the front end can not. Is this true?
> > > Also, why should the front ends do it, if it can be done correctly in
> > > one place?
>
> > Then why are you trying to return symtab->dirname at all?  Or have I
> > misinterpreted you, and you were returning symtab->fullname?  I don't
> > think symtab->dirname should be exposed in this interface.
>
>
> Yes, please excuse me. I am only interested in returning the fullname to
> the front end. I agree with you, symtab->dirname is only useful
> internally in resolving the fullname.
>
>
> > > As far as I know, most existing front ends use annotate level 1-2-3 to
> > > figure out where the source file is. I just want to simplify this
> > > process, so that front ends can easily get the absolute path to the
> > > source file without having to run multiple commands, like the CLI.
>
> > This sounds like the front end is only ever interested in one source
> > file at a time, so that would be a more efficient design than asking
> > GDB to provide fullnames for every source file at once.

To badly generalize, front ends come in two flavours:

- integrated IDEs such as eclipse where the front end thinks it knows 
everything

- lighter weight debugger interfaces (Insight, xxgdb, ...) where, 
instead, GDB is relied on for the information

In the latter case a full and correct list of file names is entirely 
reasonable. e.g., for a filename tab or filename browser.

> Here there is several points to make.
>
> 1. The front should be able to get the fullname for a single source.
>
> -file-list-exec-source-file currently returns the fullname of the
> currently executing file. Which btw, has already had it's symtab read
> in. This is why symtab->dirname is set, and the fullname is accessible.
>
> An parameter should be added to -file-list-exec-source-file. So it can be
> invoked like "-file-list-exec-source-file foo.c"
> With this new command, the user should get the fullname of a particular
> source file, which means reading in the symtab, or modifying the psymtab
> to have the dirname in it.

As the doco suggests, the command's spec came from knowing that 
equivalent functionality was required by Insight (see gdb_listfiles in 
that code base).

I think -file-list-exec-source-files should take the wild card (and not 
-file-list-exec-source-file) because that is returning a list, its only 
a small jump to have it return a qualified list.

Also ...

> 2. The user should be able to get all of the fullnames with
> -file-list-exec-source-files?
>
> Currently, -file-list-exec-source-files, prints all of the "filenames"
> by looping through the symtabs and psymtabs. It knows the fullname to
> most of the symtabs, and none of the psymtabs. So, for some files, it
> prints the filename, along with the fullname, and for others it just
> prints the filename.
>
> If it just lists the "filename" and the front wants the "fullname", it
> can use the "filename" as the parameter to -file-list-exec-source-file,
> which will return the "fullname".
>
> However, if the front end wants all of the fullnames, should we make it
> send N commands to -file-list-exec-source-file, or should
> -file-list-exec-source-files take an optional parameter to force it to
> find all of the fullnames?

(Yes, making a front end do that would be dumb :-)

> Basically, this means, GDB will give you all the "filenames" (keys) of
> the current executable. Then, if you want the "fullname"(value), use the
> "filename"(key) as an argument to -file-list-exec-source-file which will
> return the "fullname"(value).
>
> Hmmm, is this a little to confusing?

... I'd specify the interface such that it is expected to return fully 
qualified file names.   I don't think anything less than that is useful.

So ... what I think has been identified is the need for a symtab query 
that returns a list of the currently known fully qualified source files. 
 How the symtab chooses to implement that query is a separate problem.

This would of course make the implementation something like:

mi_file_list_exec_source_files (..)

  char **source_files = symtab_lookup_source_files (<pattern>);
  for all source_files
    generate MI output

and likely a first draft based somewhat on existing code.

Andrew