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

[Doug Evans]

On Wed, Apr 9, 2008 at 6:49 AM, Aleksandar Ristovski <ARistovski@qnx.com> wrote:
>
> Doug Evans wrote:
>  > On Mon, Apr 7, 2008 at 10:41 PM, Doug Evans <dje@google.com> wrote:
>  >> I have an occasion to revisit this:
>  >>  http://sourceware.org/ml/gdb-patches/2007-11/msg00314.html
>  >>
>  >>  Or in a different form:
>  >>  http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
>  >>
>  >>  When we last left our story, watching for a single path mismatch of
>  >>  the main source file only seemed ok.  That's what this patch does.
>  >>  It's just a minor revision of
>  >>  http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
>  >
>  > While reading end_symtab I was inspired to try again for a
>  > debug-format independent solution.
>  >
>  >
>  Haven't tested, just thinking: Will it work in this case:
>
>  Let's imagine we have two files
>  /.../foo/bar.c
>  /.../foo/baz/bar.c
>
>  First file goes something like this:
>  ..
>  #include "baz/bar.c"
>  ...
>
>  In that case we will have lbasename(mainsub->name) == "bar.c"
>  and (strcmp (lbasename (subfile->name), mainbase) == 0) (since lbasename
>  ("/../foo/baz/bar.c" == "bar.c")
>
>  So if I am not mistaken, you would have nr_matches == 1 which would lead to
>  losing info about one of the files.

In the case where /.../foo/bar.c doesn't contain anything that would
require line number info itself (e.g. all it does is #include
"/.../foo/baz/bar.c") then yes information will be lost, but in this
case there's not much information to lose ...