This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> Date: Tue, 3 May 2005 15:48:56 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> Round and round we go... I believe I just argued the same point you're
> making here a little earlier, but gave in to Bob's wishes.

Sorry, I joined the discussion in this thread only after you asked a
question about the fullname regexp on non-Posix platforms.  So _I_ am
not going round.

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

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

> The path still has value in this case even if it doesn't exist!

The same can be said about "\abc" or "d:foo".

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

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

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]