Re: gdb_realpath: dealing with ./ and ../

["Doug Evans" <dje at google dot com>]

On Jan 7, 2008 6:32 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> The reason why I agree that the changes should be done inside
> start-subfiles is that we don't want to have to handle this sort of
> problem with every debug info reader.  This was, the handling is
> centralized. It also looks a lot simpler than the patches I have seen
> that touch the DWARF reader.

To what extent is the dwarf patch more complex because it handles the
possibility of multiple matches with the basename of the main source
file.  Assume there's only one file with the basename of the main file
name and things become a lot simpler.  See
http://sourceware.org/ml/gdb-patches/2008-01/msg00090.html.
One could rewrite that patch to keep dwarf2_start_subfile, but one
would have to pass an additional parameter so it would know if it's
dealing with the main source file.  The patch as submitted just
reorganizes things so that other solutions(/heuristics) are possible
without major reworking of the code (the patch itself had to do some
reworking, but once that's done it's done (in the problem space being
discussed)).  Plus it simplifies all call sites to
dwarf2_start_subfile/start_subfile.  Previously, each call site had to
process fe->dir_index, and there are three of them.

Handling the issue in each debug info reader is an important
consideration and may or may not be a problem.  One would need to
examine to what extent the issue exists in the other readers, and to
what extent start_subfile can solve it and still be debug-format
independent without being more complex.

> The one thing that this might break, however, is when the user
> provides a relative path in the break command:
>
>    (gdb) break bar/main.c
>
> As a matter of fact, this is already broken if DW_AT_name is main.c
> and not bar/main.c. So I'm pretty sure that it'll break it more.
> But the good news is that it would be easy to fix it: Modify the
> matching to concat the dirname and basename and do the match with
> that.
>
> Does this sound like it would work?

It seems like directory names need to be included in the file name
comparison by start_subfile to some extent, otherwise headers with the
same basename will match each other.

e.g.

a/foo.h:
int afoo () { return 0; }

b/foo.h:
int bfoo () { return 0; }

foo.c:
#include "a/foo.h"
#include "b/foo.h"
int main () { return afoo () + bfoo (); }