I'm curious if anyone has had success debugging games written with the C-API and SDK 0.10.1.
The documentation briefly covers debugging and Xcode, but I have a strong suspicion that the information predates Catalina and/or Xcode 11. I reached for the example projects in the C_API tree to validate my setup, but most of those won't actually build due to obsolete Xcode project settings (32bit targeting, etc) and non-portable paths.
I know I'm largely off the reservation for using C, but I figure it makes sense to surface these problems now for sanding and buffing.
Semi-orthogonally: I'd love instructions for debugging with lldb directly rather than Xcode because it unlocks superpowers for CLion users and archaic Vim luddites.
When compiling for the Playdate simulator, you create a .dylib that has debug symbols. The simulator loads it dynamically from the resulting .pdx. Attaching your debugging to PlaydateSDK/bin/Playdate\ Simulator.app/Contents/MacOS/Playdate\ Simulator when launching you .pdx should allow you to debug your .dylib.
For CLion specifically, the instructions in "Inside Playdate with C" worked without any problems for me. After assigning the simulator binary to my target, I can click the debug button, set breakpoints, inspect variables, etc.
Unfortunately CLion fails to debug in the same manner as Xcode on both of my development machines. The debugger gets a generic error code when attempting to attach to the Playdate Simulator process — the error is consistent between Xcode, CLion, and lldb (which may all just be lldb under the hood?)
I'm charging up a very old pre-Catalina Mac to see if my project will build and debug as-is, but I'd still love to hear if anyone on Catalina is having success where I am not.
TL;DR: this comes down to entitlements, but you can work around them by re-signing the simulator with your own certificate.
I had to update a poor 2015 MBP from High Sierra to Mojave to check whether this is a Catalina-ism — it's not. Attaching a debugger to the simulator is disallowed on both Mojave and Catalina because the simulator is not signed with the com.apple.security.get-task-allow entitlement. You can get a rough overview here.
@hbehrens is it possible that you're running an older copy of the simulator binary that was unsigned or signed with different capabilities? I'd be curious to see the output of the following command:
Panic is in a tough spot here because they can't ship a notarized simulator binary with this entitlement per Apple restrictions, so the options seem to be:
Ship unsigned builds! Let chaos reign!
Ship signed but non-notarized builds with the entitlement present.
(maybe) Ship a notarized binary with the Hardened Runtime option disabled so that Developer Mode can be used to override the lack of entitlements. I'm not completely sure this would work.
Ship a notarized binary; no debugging allowed.
In the meantime, it's actually possible to re-sign the distributed simulator application with your own certificate and expanded entitlements. I'll hold off on providing instructions until someone from Panic can weigh-in to avoid starting a cargo cult.
Hey @james, I meant Xcodeproj files with references absolute paths like /Users/dave/... that aren't valid on most developer systems. In fairness, I don't know that you can resolve $HOME in those fields, but the example projects might be able to use relative paths to be buildable in-place.
(Also: I understand if Xcode-compat for examples is a non-priority, I'd rather not use it!)