Attempts to Debug x86_64 Process on M1 Mac Fails (codelldb: Bad CPU type in executable)

[ericdrobinson]

OS: macOS 12.2 VSCode version: 1.63.2 CodeLLDB version: 1.6.10 Compiler: clang-1300.0.29.30 Debuggee: x86_64-mac (ABI is N-API as this is a native Node.js extension)

Attempts to debug an x86_64 process on an M1 Mac fails immediately with an error message of "The debugger exited without completing startup handshake." The error ("Bad CPU type in executable") seems to indicate that codelldb is being run as arm64 when it should be run with x86_64.

In order to support x86_64 development on an M1 Mac, I am using an Intel-only build of VSCodium. VSCodium and all extensions run in x86_64. This is important because I'm working on a VSCode extension that does not support the arm64 architecture for legacy reasons. At any rate, it appears as though the codelldb binary is being launched as an arm64 process and failing (inspection of the file locally indicates that it's an x86_64 file...). Running that file locally in a terminal works fine. Running it as:

arch -arm64 ./codelldb

Produces:

arch: posix_spawnp: ./codelldb: Bad CPU type in executable

which is exactly the error from the output.

Verbose log

configuration: {
  name: '[lldb] Attach (Pick PID)',
  type: 'lldb',
  request: 'attach',
  pid: '${command:pickMyProcess}',
  initCommands: [ 'setting set target.max-string-summary-length 10000' ],
  __configurationTarget: 5,
  relativePathBase: '...'
}
liblldb: ~/.vscode-oss/extensions/vadimcn.vscode-lldb-1.6.10/lldb/lib/liblldb.dylib
environment: {}
params: { evaluateForHovers: true, commandCompletions: true }
arch: posix_spawnp: ~/.vscode-oss/extensions/vadimcn.vscode-lldb-1.6.10/adapter/codelldb: Bad CPU type in executable
Error: The debugger exited without completing startup handshake.

Any idea as to what's going on? Is there something I can do on my end to get the process to run correctly?

[vadimcn]

In order to debug x86_64 binaries on M1, the debugger itself must be an arm64 process. You should have installed the native version of CodeLLDB.

[ericdrobinson]

@vadimcn Huh. Well, that is... surprisingly counterintuitive based on my understanding of the rest of the stack? Any insight as to why this might be the case?

[ericdrobinson]

To be clear, I am able to debug with the Arm64 version of the debugger (which I manually downloaded from here). It is far more prone to crashing, however.

[vadimcn]

Any insight as to why this might be the case?

Don't know. Apple made it so.

It is far more prone to crashing, however.

Compared to what? I thought you said you could not debug at all before?

[ericdrobinson]

Compared to what? I thought you said you could not debug at all before?

Let me clarify: it's more prone to crashing than my previous experiences with the extension running on a 2018 MacBook Pro (clearly Intel-only). I actually don't recall having had any crashing issues at all in the past with the extension. When running in this configuration (debugging Intel builds running on Rosetta 2 on an M1 Max) I've experienced the following:

1. VSCodium's renderers crash (all windows) and need to be restarted. This effectively 100% reloads all windows. This can be triggered by simply Terminating an active Debug Session (possibly requires being stopped at a breakpoint) instead of Detaching from one. "Stopping" a debug session in this manner does not preclude a subsequent debug session from starting.
2. Clicking "continue" in this configuration after being paused on a breakpoint results in the debug session never actually continuing. The process sort of locks up. If I quit VSCodium or close the Window the extension is running within when this happens, then the parent "Electron" process appears to become orphaned and the cannot be force quit. When this happens, further attempts to start the debugger simply fail. Restarting the computer resolves the issue.

I never saw either of the above when running on the Intel-only MBP.

[vadimcn]

Sorry, I am afraid I can't be of much help here. I don't even own an M1 Mac.
From what I hear from other users, though, the native arm64 VSCode runs very well.