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

[Aleksandar Ristovski <ARistovski@qnx.com>]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: January 3, 2008 11:47 AM
> To: Aleksandar Ristovski
> Cc: gdb@sourceware.org; Ryan Mansfield
> Subject: Re: gdb_realpath: dealing with ./ and ../
> 
> 
> 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.

>Your
> patch added several calls of that sort.

No, my patch only checked if realpath returns NULL in which case instead of
returning filename as-is, it normalizes it. 

I also added gdb_realpath call in create_subfile to create canonical
pathname for a new subfile, and to canonicalize path we are looking for.

But I do not claim this is a perfect solution.

> 
> > > > When our cross-compiler generates binary, it stores relative path in
> > > > .debug_line section (relative to compilation dir), i.e. '..'.
> > >
> > > What's in .debug_info?  Also, what version of GDB?
> >
> >
> > In my case:
> >      DW_AT_name        :
> > c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc>~~~~~$
> >      DW_AT_comp_dir    :
> > c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug>~~~~~
> 
> 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.

> 
> --
> Daniel Jacobowitz
> CodeSourcery