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

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


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