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

[Aleksandar Ristovski <ARistovski@qnx.com>]

> -----Original Message-----
> From: dje@google.com [mailto:dje@google.com]
> Sent: January 6, 2008 9:24 PM
> To: gdb-patches@sourceware.org
> Cc: Aleksandar Ristovski
> Subject: RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line
> inconsistencies
> 
> How about this?
> 

By looking at the code, looks good to me, but I can also see good points in
Joel's post: http://sourceware.org/ml/gdb/2008-01/msg00048.html

Whichever approach (fix in start_subfile or dwarf2read.c) I think the
following is common:


About normalize_path: I am really missing how would symlink spoil anything.

I did a few tests:

a) No symlinks: I make my comp_dir a working directory. Then I compile
something like:
gcc ../main.cc -o main.o
debug info is:
DW_AT_NAME=../main.cc
DW_AT_comp_dir /foo/bar/obj
The Directory Table:
..
The File Name Table:$
  Entry>Dir>~~~~Time>~~~Size>~~~Name$
  1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$

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


My conclusion is that whatever gcc stores in debug info (related to paths)
should be taken as a snapshot of what it saw and we should not worry about
symlinks at all... if you can, please, give me a good example where
normalize_path would break things due to symlinks?


Thanks

Aleksandar