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

Doug Evans
2008-04-09T18:04:35Z

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