[cfe-dev] [driver] Feedback on -fdebug-compilation-dir implementation

[Chad Rosier]

All,
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?

  Chad