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


On Tue, May 03, 2005 at 10:34:15PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 2 May 2005 23:46:05 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > > > That's not what we're testing for in the testsuite, though.
> > > 
> > > What _are_ we trying to test?
> > 
> > GDB is outputting an absolute path, which will be used by either the
> > user or by a front end.  In either case, it should locate the file
> > entirely unambiguously.
> 
> If that is what we want to test, then the test is IMHO inappropriate:
> we shouldn't try to identify an absolute file name, we should see if
> the name it produces corresponds to a real file.  I.e., try to stat
> the file, or maybe cmp it against the source whose path we know, or
> something like that.

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.

These tests are not for the fullname feature.  They merely include a
fullname in their output.  I'm all for putting fullname=".*basics.c" in
them and leaving it at that.  But if we're going to be more precise,
then we should try to be completely precise; the regexp can be easily
centralized.

> > > > I think that we should reject both \abc and d:foo here.
> > > 
> > > I don't think so.
> > 
> > Could you explain why?
> 
> Because (as I said in my other mail this morning) such semi-absolute
> file names can be recorded in the debug info, albeit under somewhat
> unusual circumstances.  Since we don't own the compiler's code that
> records file and directory names in the debug info, we can never be
> 100% sure such file names will never end up there.  When they do,
> there's nothing we can do about them in GDB but try to find them, see
> below.  Failing the test because we see such file names will thus do a
> misservice to us: it will mark a perfrctly legitimate result as a
> failure.
> 
> > What should the front end receiving this information do with it?
> 
> It should do the best it can: try to access the file under the
> assumption that the missing drive in "\abc" is the current one and the
> missing directory in d:foo is the current directory on drive d:
> (which could be different from the current drive).  If that works, we
> win; if not, tough.  The failure case is the same situation as when
> the front end receives a file name which does not exist on the machine
> (e.g., a module from a library that was compiled on a different
> computer): GDB tries its best to find the file, but if the directory
> cannot be found by any algorithm known to us, we give up.  What else
> can we do?

This is where we disagree.  GDB should do the search, yes.  But it
should never ask the user to do any guessing again.  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.

The path still has value in this case even if it doesn't exist!  We
can't show the user the file, but we can use it to unambiguously place
a breakpoint in the correct file.  Of course, if GDB is reduced to
guessing, it may decide that two files who differ only in their current
directory are the same.  That's a limitation of the input debug
information in some circumstances.

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.  If we don't, who will?  We can't do simple things like
"list" if we can't find the source files.

Secondly, if we get bogus information from the compiler we will try to
resolve it.  We should not be showing the raw data to a front end, only
the resolved path.

I can see justification in reporting a non-absolute path to the user
when GDB is absolutely stumped, but that's not this case.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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