This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies
- From: Daniel Jacobowitz <drow at false dot org>
- To: Aleksandar Ristovski <ARistovski at qnx dot com>
- Cc: dje at google dot com, gdb-patches at sourceware dot org
- Date: Tue, 8 Jan 2008 11:45:44 -0500
- Subject: Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies
- References: <2F6320727174C448A52CEB63D85D11F40A62@nova.ott.qnx.com>
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