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

Aleksandar Ristovski
2008-01-03T18:30:44Z

> An alternative would be to do some canonicalization - not
> gdb_realpath, which accesses the filesystem, but just string
> manipulation - on the subfile names iff nothing matches the main
> file. You could remove the ".." there.

Allright, I will try with the alternative.

I see two problems:

1. Problem one - relative NAME and absolute subfile->name case not covered:

In function start_subfile (buildsym.c:approx 554) we completely miss one
case: when NAME is relative path but subfile->name is absolute.

I put some instrumentation to illustrate this problem. The list below says
what is happening and specifies name, directory:

start_subfile: c:/testManagedCC/main.cc, c:/testManagedCC/Debug
creating subfile: c:/testManagedCC/main.cc, c:/testManagedCC/Debug
start_subfile: ../main.cc, c:/testManagedCC/Debug
comparing: c:/testManagedCC/main.cc, ../main.cc
creating subfile: ../main.cc, c:/testManagedCC/Debug
start_subfile: ../main.cc, c:/testManagedCC/Debug
comparing: ../main.cc, ../main.cc

Then it goes on to compare ../main.cc for each line in linetable.

Note that we created two subfiles for physically one file.

2. Problem two - one physical file is specified with two pathnames.

This is the case I was talking about. To fix it, I would try a combination
of guessing/normalizing, by inserting code for "second-best" match using
normalized path (in the same loop) if FILENAME_CMP fails to match and then
if no perfect match is found, use the second-best match. Not sure what
happens if there are more than one second-best matches (you say it's going
to be very rare)... probably at least issue a warning and behave as if no
match was found? Or resort to getting the first/last second-best match? On a
second thought, if we go with the second-best match we will never get into a
situation where two created subfile-s give more two second-best matches...
it will always be either perfect match or the second-best... this should
work.

Comments?