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

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drowfalse.org]
> Sent: January 3, 2008 10:56 AM
> To: Aleksandar Ristovski
> Cc: gdbsourceware.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

On Thu, Jan 03, 2008 at 11:33:34AM -0500, Aleksandar
Ristovski wrote:
> 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).

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.  Your
patch added several calls of that sort.

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

-- 
Daniel Jacobowitz
CodeSourcery