RE: gdb_realpath: dealing with ./ and ../

Aleksandar Ristovski
2008-01-08T16:12:07Z

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

Wherever the fix is put, it will be of approx. the same complexity as it
solves the same problem in a similar way.

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

This would effectively make keeping DW_AT_comp_dir value redundant. Not sure
if this would create any issues (I don't see any).

>
> Second, I still believe at this point that the problem should be
> handled outside of the debug info reader. I know that at least
> stabs should have the same issues as DWARF. It would be very nice
> to have the problems fixed in both cases without having to duplicate
> the algorithms we're developing.

>
> > 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.
>
> 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 we can confirm for sure that "normalize_path" is safe, I think the idea
is good (please read my comment about normalize_path here:
http://sourceware.org/ml/gdb-patches/2008-01/msg00138.html)

Example
DW_AT_name=../main.cc
DW_AT_comp_dir=/foo/bar/obj
The Directory Table:
..
The File Name Table:$
Entry>Dir>~~~~Time>~~~Size>~~~Name$
1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$

Now we get rid of the comp_dir information (this is what effectively
happens):

NAME=main.cc
DIR=/foo/bar

And there is no info about /foo/bar/obj.

I would think that this is safe.

Thanks,

Aleksandar