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

[Bob Rossi <bob at brasko dot net>]

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