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

[Aleksandar Ristovski <ARistovski@qnx.com>]

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


> 
> I think we should not implement this unless we have a real-world
> example where it would be necessary.  It would require a version of
> the compiler which outputs different paths in .debug_info and
> .debug_line for the same file (which is a bug in the compiler, in my
> opinion!), a Makefile using ".." to find source files, and a source
> file including another file with the same basename.

The above is a real-world example. Note that we are not trying to solve
issue of the same file stored by two different paths in debug_info and
debug_line (that indeed would be a gcc bug) but rather to resolve the issue
of the same file stored with the same path spelled differently.


Thanks,

Aleksandar
QNX Software Systems