gdb_realpath: dealing with ./ and ../

[Daniel Jacobowitz]

On Thu, Jan 03, 2008 at 12:01:16PM -0500, Aleksandar Ristovski wrote:
> > We should not call realpath on files which are not known to exist on
> > the system running GDB.  If we do that somewhere, it's a bug.  
> 
> I am not sure it is a bug. At the time of gdb_realpath call, gdb can not
> know whether the path exists or not, it takes the path information from
> debug info. Second, it is perfectly normal situation where sources are not
> available at all, and paths mentioned in debug_info do not physically exist
> on the system.

Paths from debug info are adjusted before we treat them as local
paths.  e.g. set substitute-path.

> > Well, that's why.  If DW_AT_name was main.cc, things would have
> > worked.  That's what GCC generates for me.  You have debug info which
> > refers to the same file using two different pathnames.
> > 
> > Perhaps we can forcibly associate the compilation unit with the first
> > entry in the file name table, if they have the same basename and no
> > other file in the line table matches the CU better.
> 
> Would this not introduce a bit of guessing? Consider a case where there are
> several files with the same basename but different paths (possibly specified
> using relative path elements, i.e. different pathnames like in my case). In
> this case none of the files with the same base name would perfectly fit and
> picking the first one will likely not give the correct answer.

It's a guess, but a good one.  99.9% of the time, a C file does not
include another C file with the same basename.  If the compiler is
going to generate debug info which refers to the same file by two
different names, I don't see what else we can do.

An alternative would be to do some canonicalization - not
gdb_realpath, which accesses the filesystem, but just string
manipulation - on the subfile names iff nothing matches the main
file.  You could remove the ".." there.

-- 
Daniel Jacobowitz
CodeSourcery