Re: gdb_realpath: dealing with ./ and ../

Daniel Jacobowitz
2008-01-03T17:13:54Z

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