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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
