Re: [RFC] Don't lose compilation directory in Dwarf2 line-tables

[Daniel Jacobowitz <drow@false.org>]

On Fri, Apr 14, 2006 at 10:22:56AM +0200, Frederic RISS wrote:
> > When dirname is relative, I guess we lose information by concatenating
> > it with comp_dir, but I don't see where we would ever use that
> > information. 
> 
> I see 2 uses for that:
>  - differentiating identically named source files in different parts of
> the source tree. One great example of that is a Linux kernel: try
> something like 'find include -name cache.h' at the root. This works
> for .c files because they get their relative directory in their
> DW_AT_name.
>  - If you move your build tree (or in a networked environment, when you
> access it from another mount point), then you just have to point 'dir'
> at the new root, and all the files should be found. Right now, if you
> have more than one include dir, you have to add themm all to the source
> search path.

Now, these are useful things to do.  But, it's too compiler-dependant,
and build system dependant, to do it this way.  Consider: you are
relying on the fact that line table entries are relative to the
comp_dir, and that many files have the same comp_dir.  Linux 2.6 does
build things this way.  2.4 built from subdirectories.  Coincidentally,
so does GDB.

For an alternative approach, see this:
  http://sourceware.org/ml/gdb/2006-03/msg00189.html

I think that may be a better solution; Paul, are you going to post
that?  Please? :-)

That said, I don't much care which bits get concatenated with which
other bits; as you found, it doesn't seem to make a lot of difference
(and I'm of the opinion that it shouldn't make a difference).  Doing
it your way may be most useful.  But I'd like a solution to the moved
source tree problem which doesn't rely on this compiler behavior.

-- 
Daniel Jacobowitz
CodeSourcery