Re: [RFC] fullname attribute for GDB/MI stack frames

[Daniel Jacobowitz <drow at false dot org>]

On Tue, May 03, 2005 at 11:46:26PM +0300, Eli Zaretskii wrote:
> > This is where we disagree.  GDB should do the search, yes.  But it
> > should never ask the user to do any guessing again.
> 
> I'm not sure we understand each other: who said anything about
> guessing or asking the user to do so?

I consider printing "d:foo.c" to be "asking the user to guess".  We
didn't tell them where the file was.

> > GDB has to settle on a path eventually, whether or not that path
> > ends up containing the file.  I believe that GDB should settle on a
> > path and report it precisely to the user.
> 
> And where does this contradict anything that I said?  For that matter,
> how is this at all related to the issue we are discussing, which I
> thought was how to test the output of the fullname attribute?

If GDB has settled on a path, it can fully resolve it and display it to
the user.  For instance, suppose that the best GDB can glean from the
debug information is "d:foo".  That's equivalent to "d:./foo".  I
presume that DJGPP has some concept of "get the current directory on
drive D".  So GDB could print out "d:/some/directory/foo" instead.
I also presume that there's an equivalent "get current drive" for the
"\foo" case.

Why don't you want it to do that?

> > The path still has value in this case even if it doesn't exist!
> 
> The same can be said about "\abc" or "d:foo".

Everything has value... but that has less, because of this:

> > We can't show the user the file, but we can use it to unambiguously
> > place a breakpoint in the correct file.
> 
> The same can be said about "\abc" or "d:foo".

No, I don't think it can.  The difference between an absolute path and
a partially relative path is that an absolute path has no implicit
information.  If GDB reports that one file includes a header c:\abc and
another includes \abc, the front end has to guess whether GDB considers
those the same file or not.

> > First of all, in the testsuite we know the file will exist.  If GDB can
> > not find it, that's a bug.  No matter what.  It may be a bug in GDB or
> > a bug in the compiler, but it is a bug, and I want the testsuite to
> > detect it.
> 
> Then let's do what I suggested: take the value of fullname and see if
> we can reach the file it names.  There's no need for any regexp at
> all; moreover, even if we agree on some regexp, it is only a fuzzy
> test, since the fact that the output matches does not yet mean that
> the output is correct.

Then the value GDB uses will be based on its current directory or
drive, and the value the testsuite uses will be based on its own
current directory or drive.  I don't think that's an improvement.

> > Secondly, if we get bogus information from the compiler we will try to
> > resolve it.
> 
> Unfortunately, there's no specification known to me as to what can and
> cannot be recorded in the directory name of the source file in the
> debug info, at least not for Windows filesystems.  I think I once saw
> a "../../foo/bar/baz.c" there, for example.  So we cannot easily
> detect ``bogus'' here.

What I meant here by "resolve" is the same as I meant below.  If we get
../../foo/bar/baz.c in the debug information, that's fine; GDB will try
to resolve it relative to $cdir if it can.  If it can, then it will
pass the whole thing to lrealpath.

> > We should not be showing the raw data to a front end, only
> > the resolved path.
> 
> I don't think this is a good idea, because we don't have enough
> information.  If we try to resolve and the path winds up with
> incorrect value, the user will be unable to access the source file.
> OTOH, if we leave these semi-absolute file names intact, the user
> could remedy the situation by using the `cd' command from inside GDB.

"info source" exists to show the user this sort of detail.

-- 
Daniel Jacobowitz
CodeSourcery, LLC