This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb_realpath: dealing with ./ and ../
- From: Daniel Jacobowitz <drow at false dot org>
- To: Aleksandar Ristovski <ARistovski at qnx dot com>
- Cc: gdb at sourceware dot org, Ryan Mansfield <RMansfield at qnx dot com>
- Date: Thu, 3 Jan 2008 12:08:46 -0500
- Subject: Re: gdb_realpath: dealing with ./ and ../
- References: <2F6320727174C448A52CEB63D85D11F40A3F@nova.ott.qnx.com>
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