I confess that I may have been overly optimistic about stating here that I could successfully debug with the simulator from Fire with Mercury. It launched my app on the simulator so I thought I was good to go. However it gets stuck on the launch storyboard and never is able to successfully attach to the process. If I deploy without running then it continues to my Main storyboard.
I’ll have a look tomorrow. Right now, M1 support is a bit limited, as we don’t have/are not using the old LLDB-based debug engine on arm, but the more experimental Island engine. We’ve made a lot of progress supporting macOS local debugging this past week (it works mostly perfect now, some speed issues aside thatchers still investigating), but we haven’t tested the Simulator/x64 on arm64 situation yet (and we’re making progress on the on-devide) issue.
If we cannot fix sim by the next build, what I’ll do is make a change that allows you to pick the old LLDB debug engine when forcing Fire to run as x64, as as temp workaround. It let’s see what we find when I have a look at this with my colleague from the debugger team, tomorrow.
I assume you don’t have Access to an Intel Mac, in the mean time?
Ps, from the error, it looks like the problem. Is that debugserver is reporting arm64 as the architecture, even though the process is (of course) x64… that should be something we can, at the very least, hack around…
Thanks! Since I’m mostly just experimenting and learning iOS/Elements/Fire at this point, I mostly just wanted to make sure I wasn’t doing anything wrong. While we do have a couple of Intel Macs here, they are pretty old and being used for other purposes, so not really worth the effort for me to setup just to learn.
If I had the ability to debug on either the simulator or a device in the next month or two, that would probably meet my needs just fine. So don’t feel like you have to do something hacky and temporary just for me, if a more permanent solution is just around the corner.
Thanks again Marc - I really appreciate your efforts!
Ok, I definitely expect these kings to be worked out in the next week or two, yeah.
That said, expect the iOS toolchain to always be a bit flaky, especially the Simulator. For exam please, right now as im trying to repro the issue you reported, I cant get the Simulator to boot. Or rather, it boots fine, bit the (official!) API we use t control it keeps telling me it’s not booted yet.
It’s a(n out of our control) mess.
I hardly ever do active debugging on iOS for that reason. I usually jus rely on NSLog
That’s good to know! I saw that same issue with it not seeing that the simulator was booted up, and I just assumed that I was doing it wrong - that I had to start the correct simulator separately before starting debugging.
Thanks for the pointer to NSLog - something else to investigate.
I used to do development for the Pocket PC 20 years ago, and debugging was always challenging and flaky. It is actually a bit depressing to realize that some things never change!
Curious, but yours eventually got detected as booted, ok? what changed?
I assume that like me you’re on Xcode 4.3 GM, which is the latest?
indeed. Just wait will you wanna target the Watch…
I do remember the Pocket PC days fondly. I had the original Casio Cassiopeia (loved it), as well as a Vadem Clio (a device way ahead of its time). But developing for them was a pain. Only time I ever used Visual C++, IIRC. nightmares .
What seemed to work better for me was to open my simulator device first so that it was booted, and then start deploy/debugging. Then it reports “Simulator is already booted” and moves on.
Where would I see this? In “About Xcode”, it shows a quite different number: 12.3 (12C33)
Oh my! I remember the Clio! Yes, way ahead of its time! The Pocket PC development work I was doing was in VBScript: so, so ouchy!
Also fixed the issue with debug server running as arm64 (it was a holdover bug from before Fire was ported to arm — it enforced x86_64 when needed, but only when Fire was an x86_64 process).
This fix works, and fixes switching between arm64 and x86_64 for Mac apps (which was also broken as part of the same issue; it’d always run the arm64 slice, if present), but unfortunately it does not fix there iOS problem:
Running /usr/bin/arch -x86_64 /Users/mh/Applications/Xcode-12.3.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver -f16 --log-file /dev/stdout 0.0.0.0:39902 --attach=43048
debugserver-@(#)PROGRAM:LLDB PROJECT:lldb-1200.0.44
Trying to attach to a translated process with the native debugserver, exiting...
for x86_64.
Attaching to process 43048...
despite it property running as and detecting x86_64, it still emits the “Trying to attach to a translated process with the native debugserver, exiting...” error (even though, no, it’s not the native debugserver).
since this fix works for macOS (and its the same debugserver), I’m tempted to believe that this might just not be supported at all, and we will have to wait for the original issue with linking arm64 simulator binaries to be fixed… I’ll escalate priority for that with the compiler team.
.