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

[Aleksandar Ristovski <ARistovski@qnx.com>]

> >
> > How about this?
> > Aleksandar, does this work for you? [you'll need to still account for
> > IS_ABSOLUTE_PATH issues I suspect]
> >
> > This patch has dwarf_decode_lines prescan the .debug_line info for
> > files that match DW_AT_name of the main source file, and passes that
> > to start_subfile instead of what's recorded in .debug_line.  This lets
> > start_subfile get a match with the initial subfile created by
> > start_symtab.

IMHO, this is the right direction. 

> >
> > I took an easy out in scanning for a match, I just pick the first.  I
> > can add the requisite code if folks think this is the way to go.

I would think that yes, we need to do more to try "perfect" v.s. "less than
perfect" matches. 

I still believe we should do the following (I am assuming cu_file_name is an
absolute path).

1) Compare cu_file_name and fname; make sure fname is absolute, concat if
needed. They match? Great - pick that one.

2) Try less than perfect match: compare base names; Loop, however, through
all and see if exactly one match exists. If yes, great - pick that one. 

3) If neither 1 or 2 worked, try with compacting absolute paths and
comparing compacted paths. If it matches, pick that one. If not... don't
know.

Note: I don't think possibility of symlinks will spoil step 3. We simply try
to match compiler's idea about what it saw. I.e., at this point we are
playing with paths only (we can think of them as logical paths since
physical paths at this point may not exist at all on the host system where
gdb is running. In fact, we do not really care what the physical path is we
just want to reconstruct what compiler thought it compiled). 



Thanks,

Aleksandar