Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jan 08, 2008 at 11:33:28AM -0500, Aleksandar Ristovski wrote:
> 
> 
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@false.org]
> > Sent: January 8, 2008 11:19 AM
> > To: Aleksandar Ristovski
> > Cc: dje@google.com; gdb-patches@sourceware.org
> > Subject: Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco
> > nsistencies
> > 
> > On Tue, Jan 08, 2008 at 11:09:18AM -0500, Aleksandar Ristovski wrote:
> > > b) Symlinks involved:
> > > b1) Then I tried to make a symlink to another location:
> > > ln -s /tmp /foo/bar/obj
> > > Make /foo/bar/obj my work dir and try:
> > > gcc ../main.cc
> > > It fails to find it (and rightfully so).
> > > The only way I could build it is by using the absolute names.
> > > gcc -c -g /foo/bar/main.cc  -o main.o
> > > now DW_AT_comp_dir is not specified and all paths are absolute (so no
> > > problems there).
> > 
> > No, try:
> > 
> > mkdir -p /foo/bar/real-obj/obj
> > touch /foo/bar/real-obj/main.c
> > rm /foo/bar/obj
> > ln -s /foo/bar/real-obj/obj /foo/bar/obj
> > cd /foo/bar/obj
> > gcc ../main.c
> > 
> > The path "/foo/bar/obj/../main.c" is valid.  The path
> > "/foo/bar/main.c" is not.
> I recreated your case.
> My physical path:
> 
> My compiler generated this:
>      DW_AT_name        : ../main.cc>~~~~$
>      DW_AT_comp_dir    : /foo/bar/obj>~~~~
>  (note how it stored symlink in comp_dir)
> The Directory Table:$
>   ..$
> $
>  The File Name Table:$
>   Entry>Dir>~~~~Time>~~~Size>~~~Name$
>   1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$
> 
> 
> I still don't see the issue. The mere fact that my /foo/bar/main.cc does not
> really live there but rather in /foo/bar/real-obj doesn't make any
> difference for resolving debug_info and debug_line information. Gcc thought
> it was there, that should be good enough for gdb.

The above line table will never provoke the bug that we have been
discussing.  You have "/foo/bar/obj" as the compilation directory.
In .debug_info you have "../main.cc" appended to that.  In .debug_line
you have ".." and "main.c" appended to it.  GDB will get the same
result from both.

Your original example had
"c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" for the
name, "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug" for
the compilation directory, and ".." and "main.c" in .debug_line.
So .debug_info said
"c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" and
.debug_line said
"c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug/../main.cc".
If there had been a symlink involved, those would have been different
files; they are different paths.

The compiler should never do this.  I still say that this is a bug in
the compiler.  Does a more recent version of GCC still do so?  GCC
3.3.5 predates an official FSF port to native Windows.

-- 
Daniel Jacobowitz
CodeSourcery