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

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

On Jan 7, 2008 9:45 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> I have thought this over some more, and it looks like
> indeed manual rewriting of the paths will be needed if we want to
> be able to handle all the situations currently discussed.

I think this point is still open for discussion, i.e. do we want to
try to handle "all" the situations currently discussed.  One can solve
the 99.9% case without resorting to path rewriting, one just needs to
know that one particular path is the path of the main source file.  If
one can know this (e.g. by an extra argument to start_subfile, or
because the debug info readers have enough context to know it), then
one can first do a full path comparison and if that fails and the file
is the main file then do a basename comparison.

In order to make progress I think we need to decide on whether we are
going to try heuristics (like path normalization) to handle the 0.1%
case.  The 0.1% case being multiple files with the same base name as
the main file.  [For completeness sake, there may be more cases so the
math might not add up.]  And if so we also need to decide whether
heuristics (like path normalization) will be applied to all files, or
just the main file.  The proposed patch applies normalization to all
files, the dwarf patch applies it to just files that are potentially
the main file and then only if there are multiple files with the same
basename as the main file.

Of course, we also need to decide on whether we're going to handle
this problem at all. :-)  Producers of debug info should follow rules
more strictly, but I think consumers of debug info should be a bit lax
if it's easy to do and reasonably useful.  [One can still flag
violations with complaints so producers get fixed - that's one thing
that should be added to any patch that goes in.  The dwarf spec is
silent on this issue but I gather the intent is that paths must be
consistent - this may get fixed in dwarf v4.]

> Maybe I shouldn't have talked about complexity as this may be just me
> needing time to understand the purpose of your patch. So I withdraw
> that comment.

Also remember that that patch also adds some simplification: All three
call sites of dwarf2_start_subfile currently process fe->dir_index.
One could move that into dwarf2_start_subfile of course, but there is
still the issue of knowing a file is the main file.

> My suggestion has two ideas behind it:
>
>     I reallly think that the wrapper around start_subfile that adjusts
>     NAME and DIRNAME so that NAME is always a basename is a good step
>     forward, because it reduces the number of combinations we need to
>     handle during the matching phase later on.  We don't have to handle
>     the case where NAME is a full path, or a relative path of a basename.

Or one could instead store basename and fullname in struct subfile
(where "fullname" is the complete path that's available).  This way
the comparison loop in start_subfile doesn't have to keep prepending
directories, and can go back to the simple loop it use to be.  [I
still have an open question regarding why DIRNAME isn't prepended to
NAME before going into the comparison loop:
http://sourceware.org/ml/gdb-patches/2008-01/msg00091.html]

> I think that the reorganization will not be necessary.  I'd like to
> make the subfile layer work in a way that the debug info reader would
> only have to pass the name and dirname as-is, and be confident that
> it'll just work.

If one wants to handle this, and one wants to handle it in
start_subfile, then I think start_subfile needs to know when it is
passed the main file so that it can punt to heuristics only in this
case.  start_symtab is presumably a good place to tell start_subfile
"this is the main file".  Either that or maybe use last_source_file.