This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: gdb_realpath: dealing with ./ and ../
- From: Aleksandar Ristovski <ARistovski at qnx dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org, Ryan Mansfield <RMansfield at qnx dot com>
- Date: Thu, 3 Jan 2008 13:25:55 -0500
- Subject: RE: gdb_realpath: dealing with ./ and ../
> 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?