RE: gdb_realpath: dealing with ./ and ../

[Aleksandar Ristovski <ARistovski at qnx dot com>]

> 
> On Fri, Jan 04, 2008 at 01:39:51PM -0800, Doug Evans wrote:
> > The use of #line in the testcases in the appended patch is
> > questionable, but as a data point the testcases fail without the patch
> > and pass with the patch.  These versions of the testcases have been
> > amended to use substitute-path.
@Doug:
Without trying-out your patch, by just looking at it, I don't think it
solves testcase number 2 from my previous post:
http://sourceware.org/ml/gdb/2008-01/msg00024.html 
This test case was my initial issue I wanted to solve, and then other issues
come up.

So my original problem was not related to using substitute-path (the
inconsistency of substitute-path should probably be discussed in a separate
thread), but in having two pathnames for the same physical path. One comes
from
DW_AT_name
And is a full file name, e.g. /foo/bar/main.cc
Second is constructed from .debug_line information, by concatenating
directory (which is "..") and file name ("main.cc") giving "../main.cc"
which is then appended to DW_AT_comp_dir resulting in:
/foo/bar/Debug/../main.cc

Now in start_subfile we are comparing:
/foo/bar/main.cc for which subfile structure had been constructed already
and
/foo/bar/Debug/../main.cc
Which should yield to finding the already constructed structure, but since
FILENAME_CMP does fairly simple file comparison, it fails to match it and
then goes on to create new subfile structure which is wrong. 

After that, another lookup is done and the first subfile is found (using
/foo/bar/main.cc) but due to no line information associated with it, gdb
fails to find info about that line and displays the error message to the
user (something like "no line NN in main.cc").


> 
> This happens during symbol reading, right?  That means substitute-path
> has to be set before GDB loads any files; another reason why I don't
> think it is appropriate to use it while building symtabs.
> 
> I'll look at the rest of this thread later.


Part of the solution to the testcase 2 is to add opposite case (we are
checking only IS_ABSOLUTE_PATH (name)... but we do not cover the case where
NAME is relative (and existing subfile->name is absolute, which is exactly
my case).

Maybe the other part of the solution to testcase 2 should really be in
rewriting FILENAME_CMP to try other alternatives if simple comparison fails.
It could remove '..' path elements and it would be safe if we are dealing
with paths coming from the binary.

> 
> --
> Daniel Jacobowitz
> CodeSourcery