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

[Frederic RISS <frederic.riss@st.com>]

On Fri, 2006-04-14 at 10:04 -0400, Daniel Jacobowitz wrote:
> 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.

Very true... I thought that doing it this way would solve a more general
problem, but in fact when your project has several compilation
directories it totally fails!

> 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? :-)

Seems I missed this thread. The idea is excellent.

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

I don't have clear-cut opinion anymore either. If Jim expresses no other
opinion until then, I'll send a patch implementing his suggestion
beginning of next week.