... | ... | @@ -76,7 +76,10 @@ The remaining models will have three open. |
|
|
|
|
|
## valgrind on a Mac
|
|
|
|
|
|
must include this option
|
|
|
Security features in MacOS forbid Valgrind from doing some of its operations. Xcode has similar capabilities. See this thread[ on StackOverflow](https://stackoverflow.com/questions/65009780/macos-valgrind-alternative)
|
|
|
|
|
|
|
|
|
~~must include this option
|
|
|
|
|
|
--dsymutil=no|yes [no]This option is only relevant when running Valgrind on Mac OS X.
|
|
|
|
... | ... | @@ -87,7 +90,7 @@ With --dsymutil=no, Valgrind will detect cases where the .dSYM directory is eith |
|
|
With --dsymutil=yes, Valgrind will, in such cases, automatically run dsymutil as necessary to bring the debuginfo up to date. For all practical purposes, if you always use --dsymutil=yes, then there is never any need to run dsymutil manually or as part of your applications's build system, since Valgrind will run it as necessary.
|
|
|
Valgrind will not attempt to run dsymutil on any executable or library in /usr/, /bin/, /sbin/, /opt/, /sw/,/System/, /Library/ or /Applications/ since dsymutil will always fail in such situations. It fails both because the debuginfo for such pre-installed system components is not available anywhere, and also because it would require write privileges in those directories.
|
|
|
|
|
|
Be careful when using --dsymutil=yes, since it will cause pre-existing .dSYM directories to be silently deleted and re-created. Also note the dsymutil is quite slow, sometimes excessively so.
|
|
|
Be careful when using --dsymutil=yes, since it will cause pre-existing .dSYM directories to be silently deleted and re-created. Also note the dsymutil is quite slow, sometimes excessively so. ~~
|
|
|
|
|
|
-----
|
|
|
|
... | ... | |