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

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

On Fri, 2006-04-14 at 00:41 -0700, Jim Blandy wrote:
> On 4/14/06, Frederic RISS <frederic.riss@st.com> wrote:
> > > - Then, at the top of dwarf2_start_subfile, check if dirname is
> > > relative, and if comp_dir is available, prepend comp_dir to it.  At
> > > this point, we know dirname is as absolute as it can be.  Then proceed
> > > as in the original unpatched code.  (Watch out for allocation issues.)
> >
> > I don't think we should concat comp_dir and dirname. In my mind,
> > comp_dir makes only sense as an 'independant' information. Or the other
> > way around: dirname gives you information about your source tree
> > structure, and you lose it by prepending comp_dir to it. Have you an
> > objection to storing "dirname/filename" as filename and comp_dir as
> > directory? Maybe this makes only sense when dirname is also relative
> > like in the snippet that Jason posted. Once we agree on this part, I'll
> > post an updated patch.
> 
> We agree that, when dirname is absolute, comp_dir shouldn't get used at all.

OK

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

>  I think the filename passed to start_subfile should be
> free of leading directory components; I believe this is necessary to
> make things like "print 'foo.c'::x" work.

I don't think it is necessary, because I have examples of this working
here. Moreover, if you're right on this, then we should add another
patch that sanitizes DW_AT_name before creating symtabs. Like I said in
my first mail, if the compiler accesses your source file with a relative
path, then you'll get a relative path in the comp unit's DW_AT_name. But
I'm quite sure that this would break some setups. 

I just looked up why it isn't an issue to have relative paths in the
symtab's filename. In symtab.c::lookup_symtab, after a search on the
full symtab name we do:

  /* Now, search for a matching tail (only if name doesn't have any dirs) */

  if (lbasename (name) == name)
    ALL_SYMTABS (objfile, s)
    {
      if (FILENAME_CMP (lbasename (s->filename), name) == 0)
	return s;
    }