Debugging C++ mex files in Xcode 7 on El Capitan

I have just migrated to MAC OS, and am trying to debug a mex file for the first time. I'm using MATLAB R2015b and Xcode 7.0.1 on OS X 10.11 (El Capitan). I've followed the instructions here:

http://uk.mathworks.com/help/matlab/matlab_external/debugging-on-mac-platforms.html#bt9vdq9-1

When I hit Command-R I see "Running StartMATLAB : debug" in the status bar at the top of the Xcode window. However, shortly afterwards that changes to "Finished StartMATLAB : debug", and MATLAB never actually appears.

Another thing I've tried is attaching Xcode to the MATLAB process. If I have the JVM running, it continuously hits breakpoints in assemble code, even before I call my code. If I run with the -nojvm option and attach the debugger, it doesn't stop on my breakpoints.

I should add that I'm compiling the mex file from within MATLAB. Perhaps Xcode is not watching the mex library that gets built, unlike if I do the same thing in Visual Studio.

Incidentally, I use the fix described here to use Xcode 7 and El Capitan.

Any help much appreciated.

Answer 1

[Oliver Woodford]

I have been able to hit a breakpoint in my mex code, within the Xcode IDE, by doing the following steps:

1. Building the mex file from within Xcode
2. Starting MATLAB in a terminal window by calling "matlab -nojvm"
3. Attaching Xcode to the MATLAB process
4. Putting a breakpoint in my mex function
5. Calling my mex function from MATLAB

This isn't ideal because I had to compile the mex library/application from within Xcode, rather than the normal way I do it, which is just on the MATLAB command line with my own special script. I think there must be a command line option for the compiler which I'm not using in my script, but the Xcode project is. I use only the -g option. The Xcode project uses:

-x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack
-fmacro-backtrace-limit=0 -std=gnu++11 -stdlib=libc++ -fmodules -gmodules
-fmodules-prune-interval=86400 -fmodules-prune-after=345600
-fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module
-Werror=non-modular-include-in-framework-module -Wno-trigraphs
-fpascal-strings -O0 -fno-common -Wno-missing-field-initializers
-Wno-missing-prototypes -Werror=return-type -Wunreachable-code
-Werror=deprecated-objc-isa-usage -Werror=objc-root-class
-Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors 
-Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label
-Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body
-Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants
-Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion 
-Wenum-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DMATLAB_MEX_FILE -D_MATLAB_=806
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof
-mmacosx-version-min=10.11 -g -fvisibility-inlines-hidden -Wno-sign-conversion

Answer 2

[Oliver Woodford]

I build the mex file as a command line project in Xcode, using the following custom build settings:

I then copy the mex file to where it should be with a build phase copy: