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

[Aleksandar Ristovski <ARistovski@qnx.com>]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: January 3, 2008 10:56 AM
> To: Aleksandar Ristovski
> Cc: gdb@sourceware.org; Ryan Mansfield
> Subject: Re: gdb_realpath: dealing with ./ and ../
> 
> On Thu, Jan 03, 2008 at 10:20:19AM -0500, Aleksandar Ristovski wrote:
> > Hello,
> >
> > First a question, to give an idea what I am talking about and then
> detailed
> > explanation.
> >
> > Question: Should gdb_realpath deal with './' and '../' path elements and
> > compact them along with 'canonicalization' it already does?
> 
> The problem with this idea is that removing ../ is not reliably
> correct.  On Unix, symlinks allow foo/../bar and bar to be different

On linux, when realpath works all is fine and it will take care of the
symbolic links. However, the problem starts when paths do not really exist
and realpath fails. A simple example is my cross-compiled binary built on
windows, being debugged on linux. In this case, when realpath fails, I would
like to 'compact' or 'normalize' the path by resolving relative path
elements (and current path elements) thus forming canonical path, whithout
resolving symlinks (which can not be resolved since they do not exist).

Additional problem is on windows, where realpath doesn't work and
gdb_realpath usually simply returns the input parameter. (my proposed patch
doesn't solve this... it is not complete yet).

> directories.  We should only canonicalize paths to local files, not to
> files mentioned in debug information.
> 
> gdb_realpath shouldn't need any changes to handle ..; it works from
> the local filesystem and constructs a real canonical path.  I see that
> you're on Windows.  gdb_realpath may not handle Windows correctly;
> libiberty's lrealpath does and I don't know why we still have both.

I don't think lrealpath would work in case the real path doesn't exist.

> 
> > 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>~~~~~

GDB version 6.7.

> 
> I have:
> 
>  <0><154>: Abbrev Number: 1 (DW_TAG_compile_unit)
>   <189>     DW_AT_name        : ../main.c
>   <193>     DW_AT_comp_dir    : /home/drow/z/baz
> 
>  The Directory Table:
>   ..
> 
>  The File Name Table:
>   Entry Dir     Time    Size    Name
>   1     1       0       0       main.c
> 
> So everything constructs the same /home/drow/z/baz/../main.c.
> 
> --
> Daniel Jacobowitz
> CodeSourcery