[PATCH] D9600: Add scan-build python implementation

[Devin Coughlin via cfe-commits]

dcoughlin added inline comments.

================
Comment at: tools/scan-build-py/README.md:85
@@ +84,3 @@
+
+The 2. mode is available only on FreeBSD, Linux and OSX. Where library preload
+is available from the dynamic loader. On OSX System Integrity Protection security
----------------
My comment about SIP on 10.11 not preventing library interposition on build tools is not correct. My apologies for the bad information. SIP does not prevent DYLD_INSERT_LIBRARIES on the build tools themselves but it *does* prevent interposition on the build tool shims in /usr/bin. These are thin shims that call the appropriate tools elsewhere and it is these shims that typical build scripts call. SIP also prevents library interposition on perl/python/etc. -- which are commonly used to drive build scripts. (For example, openssl's build script uses make to call perl to call cc). I think on Darwin we should use your wrapper-based approach (intercept-c/intercept-c++) instead. In my tests on openssl it produces the same (modulo ordering of entries) compilation database as running with library-interposition on a machine with SIP turned off.

================
Comment at: tools/scan-build-py/libear/ear.c:141
@@ +140,3 @@
+    environ = *_NSGetEnviron();
+#endif
+    if (!initialized)
----------------
rizsotto.mailinglist wrote:
> this call just sets up the `environ` variables for the `bear_capture_env_t` method, two lines down. that call saves the relevant variables... so, if before execv'ing somebody modify the variables we still have it saved. (by the way `Scons` is the tool which does this.) and when `call_execve` called it recovers from the saved environment.
> 
> there is a test against it. (tests/functional/cases/test_create_cdb.py:53)
> 
> > The issue I am seeing with library-interposition on OS X [...]
> 
> can you give me details what did you see? what was the test you were running?
You also later use 'environ' in `execv()`. But at that point the environment stashed in environ is different than the environment given to children. So in execv() rather than using 'environ' you on Darwin you would need to use '*_NSGetEnviron()'. (The behavior of 'environ' on Darwin in dylibs is different than in main executables, which is why _NSGetEnviron() exists). In any event, if only support using wrapper-based interposition (intercept-build-cc, etc.) on Darwin then perhaps we don't need to deal with this.

>> there is a test against it. (tests/functional/cases/test_create_cdb.py:53)

Interesting. Have you run the tests on OS X? Can you tell me how to run them?

================
Comment at: tools/scan-build-py/libscanbuild/intercept.py:143
@@ +142,3 @@
+        })
+    elif sys.platform == 'darwin':
+        logging.debug('intercept gonna preload libear on OSX')
----------------
I think it would be better to use the fall-back compiler-wrapper interposition on darwin. As I noted above (apologies again for the bad information) System Integrity Protection will make library-based interposition unreliable for build scripts that employ restricted executables.


http://reviews.llvm.org/D9600