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

[Daniel Jacobowitz <drow@false.org>]

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