[cfe-dev] [driver] Feedback on -fdebug-compilation-dir implementation
mcrosier at apple.com
Mon Apr 15 16:58:42 PDT 2013
The -fdebug-compilation-dir flag was added in r142633, but it does not match the behavior implemented in gcc. I wanted to discuss the tradeoffs between the two implementations and solicit advice on if we should match gcc's behavior, keep the current behavior, or implement something different.
Currently clang uses $PWD to set the -fdebug-compilation-dir flag. GCC does the same, but it also performs a stat() call on '.' and '$PWD' to verify the inode and device match. If they don't match, then the value returned by getcwd() is used.
Here's a simple example that exposes the different behavior:
% cd /tmp
% mkdir -p a/src
% ln -s a/src
% cd /tmp/src
In this context the value of $PWD is '/tmp/src', but the value returned by getcwd() is '/private/tmp/a/src'. Thus, gcc would use '/private/tmp/a/src' in this context, while clang would use '/tmp/src'.
A more concrete example would be when a developer uses 'gmake -C' on a makefile in a relative directory. Because we rely on $PWD alone, the clang driver ignores the directory specified by -C when setting the -fdebug-compilation-dir flag. If we match gcc's behavior, 'gmake -C' should will work as expected
However, the tradeoff is that we now have to unconditional perform two stat() calls and conditionally perform a getcwd() call. Roughly speaking, the three combine calls take about 1.65 microseconds on my system. Also, if the local configuration changes (e.g., the soft-link changes), then the debugger may not be able to find the debug information using the expanded path.
Does anyone have a preference between the current implementation and that which is implemented in gcc? Should we do something else?
More information about the cfe-dev