Here are some things that I had to do which are not mentioned in the tutorial: There are many things that aren't explained in the official tutorial, and it was very hard to Google the various problems I ran into. This would make the approach much more convenient than Approach 2! So I gave it a try, using the official tutorial.
ALL XCODE VERSIONS CODE
In theory, this should also let the debugger automatically locate the source code files and the DWARF data - allowing you to step through source code line by line without any extra effort. The lldb debugger has the built-in capability to connect to another machine remotely, then automatically upload the executable you want to debug to the remote machine, and then run and debug that executable.
o files which can be used to step through code line by line in a debugger? Or is it a subset of the DWARF data? Or is it something completely different?Įither way here's approach 3: Approach 3: Remote debugging from the command-line My question is - what kind of debug data is in the binaries when you don't strip them? Is it the same DWARF data from the. Now what confuses me is what role does 'code stripping' play in all of this? Because code stripping is described on the internet to "remove debug data from the exectable". However for storing and transferring the DWARF data to other machines you can also store it in so called. o files.o files are a byproduct when compiling C code (and code in other languages too?). Debuggers usually extract this DWARF data directly from. I don't really understand some things about the 'debug data' mentioned above.įrom what I gathered, this debug data normally comes in the so called DWARF data format.
ALL XCODE VERSIONS UPDATE
I'll update this once I look into it more. However I can't get Approach 3 to work at all so far.
ALL XCODE VERSIONS HOW TO
Here's an article on how to do this: approach is very promising but I gave up on it for now because the setup and debugging workflow sounds very slow and tedious and Approach 3 seemed to be much easier. You need to tell lldb how to link that data together.Some sort of 'debug data' that links machine instructions in the executable to lines in the the source code.The source code used to build that executable.The following data needs to be present on the old macOS:.To debug in an efficient way you want to be able to step through source code line by line. But the problem here is that it will only show me assembly code. The second idea is to use the lldb debugger directly from the command line on the old macOS. Approach 2: Debugging from the command-line See the bottom of this post for more info. I just tried to do the same thing with a Swift project (The other one was ObjC only) and it was so much work that I almost gave up on it. Set the Code Signing Identity to "Ad Hoc Code Sign" and disable hardened runtime on all targetsĪfter these steps I could build and debug my app on the old macOS version! Some things didn't compile properly, but luckily, in my case, this was good enough to figure out all of the bugs that were occuring on older macOS versions!.Set 'minimumToolsVersion' in Interface Builder files your Xcode version.Comment out all code that uses unavailable APIs.To get the project to compile on the old macOS version, I had to do a few more hacks: You can manually edit the project file with a text editor and decrease the objectVersion to get the project to open. I have set the Project Format to be compatible with a very old version of Xcode (8.0) but that didn't help. I have come accross 2 possible solutions: Unfortunately the latest version of Xcode that is available on the old macOS cannot open my. The idea is to just use Xcode to build and debug the project on the older macOS version.
How can I debug them?īelow are all of the approaches I'm aware of. My app has some bugs that only occur on older macOS versions.
0 kommentar(er)
