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

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

[Bob Rossi]

Hi,

I have been trying to implement -file-list-exec-source-files for some
time now. So far the command outputs the filename and fullname for each 
symtab and psymtab. The fullname part only get's output if GDB knows
what it is.

The problem is, I recently discovered that the fullname can only be
retrieved from the symtab, it can't be retrieved with just a psymtab.
The reason is because the symtab has a 'dirname' member, which is
necessary in finding the absolute path to a source file. Obviously I
can't read in all the symtabs just to get the fullname for each psymtab.

So, I have 2 solutions,
 1. Modify the psytmab to also have the 'dirname'. Which seems
 difficult. Although I do think this is the best solution. (Not knowing
 to much about psymtabs and symtabs)
 
 2. Change -file-list-exec-source-file to receive an optional filename,
 which when doing this causes GDB to read in the symtab associated with
 the psymtab. Then the fullname can be retrieved.

I believe option 2 is how the CLI works.
If you do 
   list foo.c:1
   info source
I am sure this reads in the symtab for foo.c and then it knows how to
get the fullpath. I don't really like this solution that much, so I
think it would be better to add the 'dirname' to the psymtab.

Any suggestions?
If your interested in poking around to see where symtab->dirname gets
set, look around buildsym.c:975. Does anyone know if there would be an
easy way into getting dirname set into the psymtab?

Thanks,
Bob Rossi

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

[Bob Rossi]

What do I have to do to get some feedback on this subject?

On Thu, Feb 12, 2004 at 08:29:46PM -0500, Bob Rossi wrote:
> Hi,
> 
> I have been trying to implement -file-list-exec-source-files for some
> time now. So far the command outputs the filename and fullname for each 
> symtab and psymtab. The fullname part only get's output if GDB knows
> what it is.
> 
> The problem is, I recently discovered that the fullname can only be
> retrieved from the symtab, it can't be retrieved with just a psymtab.
> The reason is because the symtab has a 'dirname' member, which is
> necessary in finding the absolute path to a source file. Obviously I
> can't read in all the symtabs just to get the fullname for each psymtab.
> 
> So, I have 2 solutions,
>  1. Modify the psytmab to also have the 'dirname'. Which seems
>  difficult. Although I do think this is the best solution. (Not knowing
>  to much about psymtabs and symtabs)
>  
>  2. Change -file-list-exec-source-file to receive an optional filename,
>  which when doing this causes GDB to read in the symtab associated with
>  the psymtab. Then the fullname can be retrieved.
> 
> I believe option 2 is how the CLI works.
> If you do 
>    list foo.c:1
>    info source
> I am sure this reads in the symtab for foo.c and then it knows how to
> get the fullpath. I don't really like this solution that much, so I
> think it would be better to add the 'dirname' to the psymtab.
> 
> Any suggestions?
> If your interested in poking around to see where symtab->dirname gets
> set, look around buildsym.c:975. Does anyone know if there would be an
> easy way into getting dirname set into the psymtab?
> 
> Thanks,
> Bob Rossi

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

[Kip Macy]

My limited experience indicates that it can take up to 7 days to get
feedback on an idea on this list. At this point the best thing to do
is sit tight :-).


					-Kip

On Sun, 15 Feb 2004, Bob Rossi wrote:

> What do I have to do to get some feedback on this subject?
>
> On Thu, Feb 12, 2004 at 08:29:46PM -0500, Bob Rossi wrote:
> > Hi,
> >
> > I have been trying to implement -file-list-exec-source-files for some
> > time now. So far the command outputs the filename and fullname for each
> > symtab and psymtab. The fullname part only get's output if GDB knows
> > what it is.
> >
> > The problem is, I recently discovered that the fullname can only be
> > retrieved from the symtab, it can't be retrieved with just a psymtab.
> > The reason is because the symtab has a 'dirname' member, which is
> > necessary in finding the absolute path to a source file. Obviously I
> > can't read in all the symtabs just to get the fullname for each psymtab.
> >
> > So, I have 2 solutions,
> >  1. Modify the psytmab to also have the 'dirname'. Which seems
> >  difficult. Although I do think this is the best solution. (Not knowing
> >  to much about psymtabs and symtabs)
> >
> >  2. Change -file-list-exec-source-file to receive an optional filename,
> >  which when doing this causes GDB to read in the symtab associated with
> >  the psymtab. Then the fullname can be retrieved.
> >
> > I believe option 2 is how the CLI works.
> > If you do
> >    list foo.c:1
> >    info source
> > I am sure this reads in the symtab for foo.c and then it knows how to
> > get the fullpath. I don't really like this solution that much, so I
> > think it would be better to add the 'dirname' to the psymtab.
> >
> > Any suggestions?
> > If your interested in poking around to see where symtab->dirname gets
> > set, look around buildsym.c:975. Does anyone know if there would be an
> > easy way into getting dirname set into the psymtab?
> >
> > Thanks,
> > Bob Rossi
>

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

[Bob Rossi]

On Sun, Feb 15, 2004 at 05:42:27PM -0800, Kip Macy wrote:
> My limited experience indicates that it can take up to 7 days to get
> feedback on an idea on this list. At this point the best thing to do
> is sit tight :-).

I wonder if there is something that could be done to improve this ...

Waiting 7 days for a response is acceptable if need be, but from a
"scheduling" point of view, it seems rather lacking.

Is there anything I could do to help improve the response time of the
GDB developers? In general, I am pretty interested in implementing some
of the missing MI commands. However, I don't really have the time to
wait 7 days for every stumbling block that I run up against.

Should I Email the MI Maintainers directly? Or would this be bad taste?

Bob Rossi

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

[Daniel Jacobowitz]

On Thu, Feb 12, 2004 at 08:29:46PM -0500, Bob Rossi wrote:
> So, I have 2 solutions,
>  1. Modify the psytmab to also have the 'dirname'. Which seems
>  difficult. Although I do think this is the best solution. (Not knowing
>  to much about psymtabs and symtabs)
>  
>  2. Change -file-list-exec-source-file to receive an optional filename,
>  which when doing this causes GDB to read in the symtab associated with
>  the psymtab. Then the fullname can be retrieved.

The question is whether this information is available without having to
read full symtabs.  Is this the dirname referenced in debug
information, or the dirname in which GDB has actually found the file?
I'm guessing that it's the latter, since so few debug readers bother to
fill in the former.  If so we would have to search the directory path
for every file when generating psymtabs, which isn't acceptable.  It
would take a fearsomely long time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

On Sun, Feb 15, 2004 at 10:30:08PM -0500, Daniel Jacobowitz wrote:
> On Thu, Feb 12, 2004 at 08:29:46PM -0500, Bob Rossi wrote:
> > So, I have 2 solutions,
> >  1. Modify the psytmab to also have the 'dirname'. Which seems
> >  difficult. Although I do think this is the best solution. (Not knowing
> >  to much about psymtabs and symtabs)
> >  
> >  2. Change -file-list-exec-source-file to receive an optional filename,
> >  which when doing this causes GDB to read in the symtab associated with
> >  the psymtab. Then the fullname can be retrieved.
> 
> The question is whether this information is available without having to
> read full symtabs.  Is this the dirname referenced in debug
> information, or the dirname in which GDB has actually found the file?
> I'm guessing that it's the latter, since so few debug readers bother to
> fill in the former.  If so we would have to search the directory path
> for every file when generating psymtabs, which isn't acceptable.  It
> would take a fearsomely long time.

Thanks for the response.

Actually, I'm pretty sure it's the former.
It's symtab->dirname, which seems to get filled in from the debug info.
It looks like symtab->dirname gets set around buildsym.c:975.
Is it bad to count on this feature if so few debug readers support the feature?
It seems that at least "stabs" supports this feature.

Currently, as far as I know, it's the only way things like annotate
1,2 and 3 work. That's the only reliable way GDB gets the absolute path
to the source file, is that correct? If there is another method GDB
figures out the absolute path to the source file, I would be interested
in hearing it.

Bob Rossi

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

[Daniel Jacobowitz]

On Sun, Feb 15, 2004 at 10:45:25PM -0500, Bob Rossi wrote:
> On Sun, Feb 15, 2004 at 10:30:08PM -0500, Daniel Jacobowitz wrote:
> > On Thu, Feb 12, 2004 at 08:29:46PM -0500, Bob Rossi wrote:
> > > So, I have 2 solutions,
> > >  1. Modify the psytmab to also have the 'dirname'. Which seems
> > >  difficult. Although I do think this is the best solution. (Not knowing
> > >  to much about psymtabs and symtabs)
> > >  
> > >  2. Change -file-list-exec-source-file to receive an optional filename,
> > >  which when doing this causes GDB to read in the symtab associated with
> > >  the psymtab. Then the fullname can be retrieved.
> > 
> > The question is whether this information is available without having to
> > read full symtabs.  Is this the dirname referenced in debug
> > information, or the dirname in which GDB has actually found the file?
> > I'm guessing that it's the latter, since so few debug readers bother to
> > fill in the former.  If so we would have to search the directory path
> > for every file when generating psymtabs, which isn't acceptable.  It
> > would take a fearsomely long time.
> 
> Thanks for the response.
> 
> Actually, I'm pretty sure it's the former.
> It's symtab->dirname, which seems to get filled in from the debug info.
> It looks like symtab->dirname gets set around buildsym.c:975.
> Is it bad to count on this feature if so few debug readers support the feature?
> It seems that at least "stabs" supports this feature.

Ah, both stabs and dwarf2 do.  Stabs does it in a mighty twisty way,
see patch_subfile_names.

> Currently, as far as I know, it's the only way things like annotate
> 1,2 and 3 work. That's the only reliable way GDB gets the absolute path
> to the source file, is that correct? If there is another method GDB
> figures out the absolute path to the source file, I would be interested
> in hearing it.

The directory search path, for instance - see source.c.  There's no
guarantee the source is where you left it.  Making an IDE rely on the
guessed-from-debug-info path is just going to get the situation
confused.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

On Sun, Feb 15, 2004 at 10:49:30PM -0500, Daniel Jacobowitz wrote:
> On Sun, Feb 15, 2004 at 10:45:25PM -0500, Bob Rossi wrote:
> > On Sun, Feb 15, 2004 at 10:30:08PM -0500, Daniel Jacobowitz wrote:
> > > On Thu, Feb 12, 2004 at 08:29:46PM -0500, Bob Rossi wrote:
> > > > So, I have 2 solutions,
> > > >  1. Modify the psytmab to also have the 'dirname'. Which seems
> > > >  difficult. Although I do think this is the best solution. (Not knowing
> > > >  to much about psymtabs and symtabs)
> > > >  
> > > >  2. Change -file-list-exec-source-file to receive an optional filename,
> > > >  which when doing this causes GDB to read in the symtab associated with
> > > >  the psymtab. Then the fullname can be retrieved.
> > > 
> > > The question is whether this information is available without having to
> > > read full symtabs.  Is this the dirname referenced in debug
> > > information, or the dirname in which GDB has actually found the file?
> > > I'm guessing that it's the latter, since so few debug readers bother to
> > > fill in the former.  If so we would have to search the directory path
> > > for every file when generating psymtabs, which isn't acceptable.  It
> > > would take a fearsomely long time.
> > 
> > Thanks for the response.
> > 
> > Actually, I'm pretty sure it's the former.
> > It's symtab->dirname, which seems to get filled in from the debug info.
> > It looks like symtab->dirname gets set around buildsym.c:975.
> > Is it bad to count on this feature if so few debug readers support the feature?
> > It seems that at least "stabs" supports this feature.
> 
> Ah, both stabs and dwarf2 do.  Stabs does it in a mighty twisty way,
> see patch_subfile_names.
> 
> > Currently, as far as I know, it's the only way things like annotate
> > 1,2 and 3 work. That's the only reliable way GDB gets the absolute path
> > to the source file, is that correct? If there is another method GDB
> > figures out the absolute path to the source file, I would be interested
> > in hearing it.
> 
> The directory search path, for instance - see source.c.  There's no
> guarantee the source is where you left it.  Making an IDE rely on the
> guessed-from-debug-info path is just going to get the situation
> confused.

I understand.

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.

The directory search path.
The compilation directory symtab->dirname.
The current directory?

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?

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.

So, I used the source search directory's and realized that that was not
enough information in order to find the absolute path to the source
file. I also needed symtab->dirname. After all, that's how annotate 1
has been working for years. I believe source.c:open_source_file is the
standard by which GDB has been serving up absolute paths to front ends
for a long time now. It basically is a wrapper to openp, except it also
knows about symtab->dirname. Without this, GDB can not find the absolute
path to source files in certain circumstances, even doing all of the
other work it does ( source search path ). For example
cd testsuite/gdb.mi/basics
gcc -g -Wall basics.c -o basics
cd ../..
gdb ./testsuite/gdb.mi/basics

With this example, GDB can not get the absolute path with openp alone.
It needs to know about symtab->dirname.

So I proposed the 2 changes above. If anyone knows how GDB could better
return the absolute path to front end's, I would be interested in
hearing it. I would be interested in implementing any alternative that
would be more efficient or correct.

Does everyone agree that GDB should be capable of returning this info?
That if GDB could not do it, a front end could not do it?
That GDB could do it once, allowing no front end to replicate this work?

Thanks,
Bob Rossi

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

[Daniel Jacobowitz]

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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

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.

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.

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?

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?

Thanks,
Bob Rossi

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

[Andrew Cagney]

> 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

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

[Bob Rossi]

I have decided on an interface. Please respond to let me know if this is
acceptable, and I will implement it. (Although I already have most of it
implemented)


1.  -file-list-exec-source-file

   This will remain the same. It only tells the front end the current
   filename,fullname and line number.

2. -file-list-exec-fetch-fullname [filename]

   This will be a new MI command.

   This will return a fullname given a filename.
   If the symtab is read in, it calls source.c:symtab_to_filename.
   If the symtab is not read in, it reads it in and calls the above
   function.

   This function is necessary because all of the other MI commands still
   output just the filename and not the fullname. For example, breakpoints,
   stack, ...

3. -file-list-exec-source-files [force_fullnames]

   This will implement an existing unimplemented MI command.

   By default, this will return 
   1. filename for each psymtab, with no fullname
   2. filename/fullname for each symtab

   If the option "force_fullnames" is passed, it will have GDB convert all
   of the psymtabs to symtabs, thus printing out the filename/fullname for  
   all symtabs. The overhead of doing this is probably high, and
   undesirable by default.

   If the front end wants to be more efficient, it could show the user the
   "filenames" and then do the "fullname" lookup just on that file. Thus,
   only reading in one symtab.


I have one last question that didn't get answered, could the psymtab be
modified to contain the dirname? I was digging through this code, but it
seems a little hard core. Would it be difficult to just parse the
dirname out of the debug info? The reason I ask is because, if this is
possible, then I would no longer care about making the "force_fullname"
optional, I would just always do it, since the symtabs would not have to
be read, thus, taking away all of the overhead.  This would defiantly be
desirable.

Thanks,
Bob Rossi

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

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> I have one last question that didn't get answered, could the psymtab be
> modified to contain the dirname?

Probably, but the dirname -> fullname conversion may be expensive - it
involves a lot of stat() calls.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> > I have one last question that didn't get answered, could the psymtab be
> > modified to contain the dirname?
> 
> Probably, but the dirname -> fullname conversion may be expensive - it
> involves a lot of stat() calls.

I could definatly use some advice getting the dirname into the psymtab.
I don't mind spending time implementing it if I could get a little
pointer in the right direction. It seems I would have to change both the
stabs reader and the dwarf2 reader. Is that correct?

I don't think the dirname->fullname conversion is bad at all. Well, at
least relative to looking up the fullname without the dirname.

Either, you lookup the fullname without the dirname, by using openp,
which has say N lookup attempts ( N-1 dir search path entries + 1
entry for the cwd ) 
   or
you lookup the fullname with dirname, by using open_source_file, which
add's 1 to that value of N ( by putting dirname in front ), and then
calls openp.

So, I think looking up the fullname with or without knowing the dirname
yeilds the same magnitude of work. However, if openp is implemented poorly, 
I could also look into that.

Bob Rossi

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

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 02:30:01PM -0500, Bob Rossi wrote:
> On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> > > I have one last question that didn't get answered, could the psymtab be
> > > modified to contain the dirname?
> > 
> > Probably, but the dirname -> fullname conversion may be expensive - it
> > involves a lot of stat() calls.
> 
> I could definatly use some advice getting the dirname into the psymtab.
> I don't mind spending time implementing it if I could get a little
> pointer in the right direction. It seems I would have to change both the
> stabs reader and the dwarf2 reader. Is that correct?

Yes, I think so.  Dwarf2 should be easy.  Stabs will be a little
harder.  Take a look at patch_subfile_names.

> I don't think the dirname->fullname conversion is bad at all. Well, at
> least relative to looking up the fullname without the dirname.
> 
> Either, you lookup the fullname without the dirname, by using openp,
> which has say N lookup attempts ( N-1 dir search path entries + 1
> entry for the cwd ) 
>    or
> you lookup the fullname with dirname, by using open_source_file, which
> add's 1 to that value of N ( by putting dirname in front ), and then
> calls openp.
> 
> So, I think looking up the fullname with or without knowing the dirname
> yeilds the same magnitude of work. However, if openp is implemented poorly, 
> I could also look into that.

My point was not that one of these would be pricier than the other, but
that they are both pricy.  For a large application, doing this
conversion for all files will substantially penalize your startup time. 
Not to mention having to redo most of it when a new dir is added...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

On Tue, Feb 17, 2004 at 02:33:27PM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 17, 2004 at 02:30:01PM -0500, Bob Rossi wrote:
> > On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> > > On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> > > > I have one last question that didn't get answered, could the psymtab be
> > > > modified to contain the dirname?
> > > 
> > > Probably, but the dirname -> fullname conversion may be expensive - it
> > > involves a lot of stat() calls.
> > 
> > I could definatly use some advice getting the dirname into the psymtab.
> > I don't mind spending time implementing it if I could get a little
> > pointer in the right direction. It seems I would have to change both the
> > stabs reader and the dwarf2 reader. Is that correct?
> 
> Yes, I think so.  Dwarf2 should be easy.  Stabs will be a little
> harder.  Take a look at patch_subfile_names.

Thanks, I think I got the Stabs version working.
Do you have a heads up for the Dwarf2 version?

Funny enough, Stabs was much easier for me to get done than Dwarf2.
I am  currently looking at the function dwarf2_build_psymtabs_hard.
Does this sound right?

As far as I know, this will be the last step to the patch I'm
generating. Also, I will only have Stabs and Dwarf-2 working. Anyone
know of another debug format I should be looking into?

Any help would be appreciated,
Bob Rossi

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

[Daniel Jacobowitz]

On Mon, Feb 23, 2004 at 08:13:35AM -0500, Bob Rossi wrote:
> On Tue, Feb 17, 2004 at 02:33:27PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Feb 17, 2004 at 02:30:01PM -0500, Bob Rossi wrote:
> > > On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> > > > On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> > > > > I have one last question that didn't get answered, could the psymtab be
> > > > > modified to contain the dirname?
> > > > 
> > > > Probably, but the dirname -> fullname conversion may be expensive - it
> > > > involves a lot of stat() calls.
> > > 
> > > I could definatly use some advice getting the dirname into the psymtab.
> > > I don't mind spending time implementing it if I could get a little
> > > pointer in the right direction. It seems I would have to change both the
> > > stabs reader and the dwarf2 reader. Is that correct?
> > 
> > Yes, I think so.  Dwarf2 should be easy.  Stabs will be a little
> > harder.  Take a look at patch_subfile_names.
> 
> Thanks, I think I got the Stabs version working.
> Do you have a heads up for the Dwarf2 version?
> 
> Funny enough, Stabs was much easier for me to get done than Dwarf2.
> I am  currently looking at the function dwarf2_build_psymtabs_hard.
> Does this sound right?
> 
> As far as I know, this will be the last step to the patch I'm
> generating. Also, I will only have Stabs and Dwarf-2 working. Anyone
> know of another debug format I should be looking into?
> 
> Any help would be appreciated,

I'd think dwarf2 would be downright easy in comparison.  All you want
is the comp_unit_die in dwarf2_build_psymtabs_hard.  read_partial_die
does not currently save DW_AT_comp_dir, the compilation directory, but
making it do so would be easy.

This will conflict with the patches I'm working on on the intercu
branch, but I can fix up the merge later - don't worry about it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

On Mon, Feb 23, 2004 at 08:55:27AM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 23, 2004 at 08:13:35AM -0500, Bob Rossi wrote:
> > On Tue, Feb 17, 2004 at 02:33:27PM -0500, Daniel Jacobowitz wrote:
> > > On Tue, Feb 17, 2004 at 02:30:01PM -0500, Bob Rossi wrote:
> > > > On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> > > > > On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> > > > > > I have one last question that didn't get answered, could the psymtab be
> > > > > > modified to contain the dirname?
> > > > > 
> > > > > Probably, but the dirname -> fullname conversion may be expensive - it
> > > > > involves a lot of stat() calls.
> > > > 
> > > > I could definatly use some advice getting the dirname into the psymtab.
> > > > I don't mind spending time implementing it if I could get a little
> > > > pointer in the right direction. It seems I would have to change both the
> > > > stabs reader and the dwarf2 reader. Is that correct?
> > > 
> > > Yes, I think so.  Dwarf2 should be easy.  Stabs will be a little
> > > harder.  Take a look at patch_subfile_names.
> > 
> > Thanks, I think I got the Stabs version working.
> > Do you have a heads up for the Dwarf2 version?
> > 
> > Funny enough, Stabs was much easier for me to get done than Dwarf2.
> > I am  currently looking at the function dwarf2_build_psymtabs_hard.
> > Does this sound right?
> > 
> > As far as I know, this will be the last step to the patch I'm
> > generating. Also, I will only have Stabs and Dwarf-2 working. Anyone
> > know of another debug format I should be looking into?
> > 
> > Any help would be appreciated,
> 
> I'd think dwarf2 would be downright easy in comparison.  All you want
> is the comp_unit_die in dwarf2_build_psymtabs_hard.  read_partial_die
> does not currently save DW_AT_comp_dir, the compilation directory, but
> making it do so would be easy.

Thanks, with your help, this turned into a 5 minute problem!
I'll be posting the patch soon, just have to clean up the code now.

Thanks a lot!
Bob Rossi

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

[Bob Rossi]

On Mon, Feb 23, 2004 at 08:55:27AM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 23, 2004 at 08:13:35AM -0500, Bob Rossi wrote:
> > On Tue, Feb 17, 2004 at 02:33:27PM -0500, Daniel Jacobowitz wrote:
> > > On Tue, Feb 17, 2004 at 02:30:01PM -0500, Bob Rossi wrote:
> > > > On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> > > > > On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> > > > > > I have one last question that didn't get answered, could the psymtab be
> > > > > > modified to contain the dirname?
> > > > > 
> > > > > Probably, but the dirname -> fullname conversion may be expensive - it
> > > > > involves a lot of stat() calls.
> > > > 
> > > > I could definatly use some advice getting the dirname into the psymtab.
> > > > I don't mind spending time implementing it if I could get a little
> > > > pointer in the right direction. It seems I would have to change both the
> > > > stabs reader and the dwarf2 reader. Is that correct?
> > > 
> > > Yes, I think so.  Dwarf2 should be easy.  Stabs will be a little
> > > harder.  Take a look at patch_subfile_names.
> > 
> > Thanks, I think I got the Stabs version working.
> > Do you have a heads up for the Dwarf2 version?
> > 
> > Funny enough, Stabs was much easier for me to get done than Dwarf2.
> > I am  currently looking at the function dwarf2_build_psymtabs_hard.
> > Does this sound right?
> > 
> > As far as I know, this will be the last step to the patch I'm
> > generating. Also, I will only have Stabs and Dwarf-2 working. Anyone
> > know of another debug format I should be looking into?
> > 
> > Any help would be appreciated,
> 
> I'd think dwarf2 would be downright easy in comparison.  All you want
> is the comp_unit_die in dwarf2_build_psymtabs_hard.  read_partial_die
> does not currently save DW_AT_comp_dir, the compilation directory, but
> making it do so would be easy.

Well, I got dwarf2 working. Thanks for the tips. I did have one other
question though. As a test, I compiled GDB with stabs ( GDB.stabs ), and 
another GDB with dwarf2 ( GDB.dwarf2 ) debug info. When I run my patched 
GDB against these with my new command I get,

./gdb -i=mi ./gdb.stabs
-file-list-exec-source-files

   I get 1245 files, and after running uniq on them I get 662 files. These
   include both headers and source files.

When I do the same thing with gdb.dwarf2,
./gdb -i=mi ./gdb.dwarf2
-file-list-exec-source-files

   I get 286 files. They are all source files, no headers.

The question is, why would I get no header files when I use dwarf2? This
also is the same output of the CLI command 'info sources'. Is there any
way I can add the headers to the output of my command? It's certainly
possible the user could set a breakpoint in one of them, so they user
should be able to select the header's from a list, which is the output
of this command.

Thanks,
Bob Rossi

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

[Daniel Jacobowitz]

On Thu, Feb 26, 2004 at 11:29:58PM -0500, Bob Rossi wrote:
> The question is, why would I get no header files when I use dwarf2? This
> also is the same output of the CLI command 'info sources'. Is there any
> way I can add the headers to the output of my command? It's certainly
> possible the user could set a breakpoint in one of them, so they user
> should be able to select the header's from a list, which is the output
> of this command.

This is due to a long-standing problem with the DWARF-2 output
generated by GCC and accepted by GDB.

If you use the intercu branch I've been working on, and build with
-gdwarf-2, you will probably see them - I'm not sure if you'll be able
to set breakpoints in them or not.

Joel also posted a workaround for this some weeks ago.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> 
>> On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> 
>> > I have one last question that didn't get answered, could the psymtab be
>> > modified to contain the dirname?
> 
>> 
>> Probably, but the dirname -> fullname conversion may be expensive - it
>> involves a lot of stat() calls.
> 

As a first cut, don't worry about performance (or more correctly 
scaleability).   Just correctness (especially of the symtab interface).

> 2. -file-list-exec-fetch-fullname [filename]
> 
>    This will be a new MI command.
> 
>    This will return a fullname given a filename.
>    If the symtab is read in, it calls source.c:symtab_to_filename.
>    If the symtab is not read in, it reads it in and calls the above
>    function.
> 
>    This function is necessary because all of the other MI commands still
>    output just the filename and not the fullname. For example, breakpoints,
>    stack, ...

Er, isn't that a bug in the other commands?

> 3. -file-list-exec-source-files [force_fullnames]
> 
>    This will implement an existing unimplemented MI command.
> 
>    By default, this will return 
>    1. filename for each psymtab, with no fullname
>    2. filename/fullname for each symtab
> 
>    If the option "force_fullnames" is passed, it will have GDB convert all
>    of the psymtabs to symtabs, thus printing out the filename/fullname for  
>    all symtabs. The overhead of doing this is probably high, and
>    undesirable by default.
> 
>    If the front end wants to be more efficient, it could show the user the
>    "filenames" and then do the "fullname" lookup just on that file. Thus,
>    only reading in one symtab.

This specification is too heavily dependant on GDB's current underlying 
implementation - symtab and psymtab are internal details and do not 
belong in this interface specification.

> I have one last question that didn't get answered, could the psymtab be
> modified to contain the dirname? I was digging through this code, but it
> seems a little hard core. Would it be difficult to just parse the
> dirname out of the debug info? The reason I ask is because, if this is
> possible, then I would no longer care about making the "force_fullname"
> optional, I would just always do it, since the symtabs would not have to
> be read, thus, taking away all of the overhead.  This would defiantly be
> desirable.

Andrew

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

[Bob Rossi]

On Tue, Feb 17, 2004 at 02:47:55PM -0500, Andrew Cagney wrote:
> >On Tue, Feb 17, 2004 at 02:12:38PM -0500, Daniel Jacobowitz wrote:
> >
> >>On Tue, Feb 17, 2004 at 02:10:05PM -0500, Bob Rossi wrote:
> >
> >>> I have one last question that didn't get answered, could the psymtab be
> >>> modified to contain the dirname?
> >
> >>
> >>Probably, but the dirname -> fullname conversion may be expensive - it
> >>involves a lot of stat() calls.
> >
> 
> As a first cut, don't worry about performance (or more correctly 
> scaleability).   Just correctness (especially of the symtab interface).

Ok.

> 
> >2. -file-list-exec-fetch-fullname [filename]
> >
> >   This will be a new MI command.
> >
> >   This will return a fullname given a filename.
> >   If the symtab is read in, it calls source.c:symtab_to_filename.
> >   If the symtab is not read in, it reads it in and calls the above
> >   function.
> >
> >   This function is necessary because all of the other MI commands still
> >   output just the filename and not the fullname. For example, breakpoints,
> >   stack, ...

Yes, I guess it's a bug. However, these commands have never returned the 
fullname. 

Here you are making a big change to the way GDB deals with front ends.
You are saying that GDB should only let the front end know about
fullnames, and know nothing about filenames.

I consider this desirable as a front end writer, since the fullname is
the only valid unique key to a front end.

It would be nice if I could do this in 2 phase's. 
First add this function, for backwards compatibility, and then, change
all the existing commands to return fullnames.

Although, leaving this function around, doesn't hurt anything.

> >3. -file-list-exec-source-files [force_fullnames]
> >
> >   This will implement an existing unimplemented MI command.
> >
> >   By default, this will return 
> >   1. filename for each psymtab, with no fullname
> >   2. filename/fullname for each symtab
> >
> >   If the option "force_fullnames" is passed, it will have GDB convert all
> >   of the psymtabs to symtabs, thus printing out the filename/fullname for 
> >   all symtabs. The overhead of doing this is probably high, and
> >   undesirable by default.
> >
> >   If the front end wants to be more efficient, it could show the user the
> >   "filenames" and then do the "fullname" lookup just on that file. Thus,
> >   only reading in one symtab.
> 
> This specification is too heavily dependent on GDB's current underlying 
> implementation - symtab and psymtab are internal details and do not 
> belong in this interface specification.

I was just showing how this interface is affected by GDB's
implementation of psymtab/symtab. The user will have no idea of these 2
concepts.

Anyways, if I can get the dirname into psymtab, this will no longer be an 
issue. The user will always get the filename/fullname combo.

With that said, do you like the implementation?

Thanks,
Bob Rossi

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

[Andrew Cagney]

>> >2. -file-list-exec-fetch-fullname [filename]
>> >
>> >   This will be a new MI command.
>> >
>> >   This will return a fullname given a filename.
>> >   If the symtab is read in, it calls source.c:symtab_to_filename.
>> >   If the symtab is not read in, it reads it in and calls the above
>> >   function.
>> >
>> >   This function is necessary because all of the other MI commands still
>> >   output just the filename and not the fullname. For example, breakpoints,
>> >   stack, ...
> 
> 
> Yes, I guess it's a bug. However, these commands have never returned the 
> fullname. 

That's cos no one thought to point out the bug :-(

> Here you are making a big change to the way GDB deals with front ends.
> You are saying that GDB should only let the front end know about
> fullnames, and know nothing about filenames.

Both:

	filename=...,fullname=...

should be output.  That's where MI is ment to be upward compatible.

> I consider this desirable as a front end writer, since the fullname is
> the only valid unique key to a front end.
> 
> It would be nice if I could do this in 2 phase's. 
> First add this function, for backwards compatibility, and then, change
> all the existing commands to return fullnames.

I'd just fix the commands as each causes a problem as otherwize ...

> Although, leaving this function around, doesn't hurt anything.

... GDB would end up having to support that command :-(

>> >3. -file-list-exec-source-files [force_fullnames]
>> >
>> >   This will implement an existing unimplemented MI command.
>> >
>> >   By default, this will return 
>> >   1. filename for each psymtab, with no fullname
>> >   2. filename/fullname for each symtab
>> >
>> >   If the option "force_fullnames" is passed, it will have GDB convert all
>> >   of the psymtabs to symtabs, thus printing out the filename/fullname for 
>> >   all symtabs. The overhead of doing this is probably high, and
>> >   undesirable by default.
>> >
>> >   If the front end wants to be more efficient, it could show the user the
>> >   "filenames" and then do the "fullname" lookup just on that file. Thus,
>> >   only reading in one symtab.
> 
>> 
>> This specification is too heavily dependent on GDB's current underlying 
>> implementation - symtab and psymtab are internal details and do not 
>> belong in this interface specification.
> 
> 
> I was just showing how this interface is affected by GDB's
> implementation of psymtab/symtab. The user will have no idea of these 2
> concepts.
> 
> Anyways, if I can get the dirname into psymtab, this will no longer be an 
> issue. The user will always get the filename/fullname combo.
> 
> With that said, do you like the implementation?

I've not looked at it in detail.

Andrew

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

[Bob Rossi]

Ok, now that I see the light, this is the only function I will need.

-file-list-exec-source-files

It will output the filename/fullname pair for every file.
This will give me
 - a mapping between relative(filename) and absolute paths(fullname)
 - compatibility with old MI functions that only return the filename

I was originally hesitant to do this because I thought I could only get
the fullname from the psymtabs by reading in the symtab. I though this
was too expensive. However, know it seems like some of the GDB
developers think I can get access to the dirname with out reading in the
entire symtab. I think this will be the easiest way to solve all of the
problems.

Thanks,
Bob Rossi

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

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 04:08:18PM -0500, Bob Rossi wrote:
> Ok, now that I see the light, this is the only function I will need.
> 
> -file-list-exec-source-files
> 
> It will output the filename/fullname pair for every file.
> This will give me
>  - a mapping between relative(filename) and absolute paths(fullname)
>  - compatibility with old MI functions that only return the filename
> 
> I was originally hesitant to do this because I thought I could only get
> the fullname from the psymtabs by reading in the symtab. I though this
> was too expensive. However, know it seems like some of the GDB
> developers think I can get access to the dirname with out reading in the
> entire symtab. I think this will be the easiest way to solve all of the
> problems.

Do we want to qualify this by shared object?

i.e. list the source files part of Application, the source files part
of libShared1.so, libc.so, et cetera?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Bob Rossi]

On Tue, Feb 17, 2004 at 04:36:59PM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 17, 2004 at 04:08:18PM -0500, Bob Rossi wrote:
> > Ok, now that I see the light, this is the only function I will need.
> > 
> > -file-list-exec-source-files
> > 
> > It will output the filename/fullname pair for every file.
> > This will give me
> >  - a mapping between relative(filename) and absolute paths(fullname)
> >  - compatibility with old MI functions that only return the filename
> > 
> > I was originally hesitant to do this because I thought I could only get
> > the fullname from the psymtabs by reading in the symtab. I though this
> > was too expensive. However, know it seems like some of the GDB
> > developers think I can get access to the dirname with out reading in the
> > entire symtab. I think this will be the easiest way to solve all of the
> > problems.
> 
> Do we want to qualify this by shared object?
> 
> i.e. list the source files part of Application, the source files part
> of libShared1.so, libc.so, et cetera?

I think that's a great idea!

Bob Rossi

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

[Alain Magloire]

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

Not entirely.  For example, Eclipse/CDT implements a mapping.
That allow folks to "map" paths to a different value.

> > Also, why should the front ends do it, if it can be done correctly in
> > one place?
> 

The source lookup is not done by gdb, when the editor comes highlighting
the line,  The IDE has a list of paths it has to search.
It is/was not that important to set gdb's directory sources.

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

Agreed, we have folks using the CDT having > 10 000 files, source lookup
is a pain.  Having the fullPath is a definitive plus, even if we do
processing like respecting the paths order and mapping.