Forum > macOS / Mac OS X

M1 Silicon launching App with LLDB Debugger fails due to arm64e



when I launch an native Apple app on an M1 Silicon (like e.g. Calculator) the launch with LDDB fails as the command line is advising to run the arm64e instead of a arm64 architecture. See the terminal output below. Launching the debugger fails as the command arch doesn't find the arm64e architecture (it would run if the arch command would request an arm64 architecture). Here is the terminal output that is execute on launching:

Last login: Tue Sep 21 18:37:17 on ttys001
/bin/bash -c 'arch -arch arm64e '/Applications/' --unix-socket=/tmp/sSwUl3 --arch=arm64e --working-dir '/' --disable-aslr --env='OS_ACTIVITY_DT_MODE=enable' --env='XPC_SERVICE_NAME=application.lazarus.freepascal.ide.1155997.1142399' --  '/System/Applications/' ; echo Process exited with status $?';exit
jst@macMini-M1 ~ % /bin/bash -c 'arch -arch arm64e '/Applications/' --unix-socket=/tmp/sSwUl3 --arch=arm64e --working-dir '/' --disable-aslr --env='OS_ACTIVITY_DT_MODE=enable' --env='XPC_SERVICE_NAME=application.lazarus.freepascal.ide.1155997.1142399' --  '/System/Applications/' ; echo Process exited with status $?';exit
arch: posix_spawnp: /Applications/ Bad CPU type in executable
Process exited with status 1
Saving session...
...copying shared history...
...saving history...truncating history files...

[Process completed]

How to fix? Where is this launch script defined (I searched for it but can't find it) ? Any hint welcome!
Side note: I compiled the 2.2.0RC1 version of the Lazarus IDE for the native aarch64 CPU on an M1 miniMac and it runs stable for me beside this issue described above.

On my M1 Mac mini:

--- Quote ---trev@macmini8 [/Users/trev] $ sudo lldb /System/Applications/
(lldb) target create "/System/Applications/"
Current executable set to '/System/Applications/' (arm64e).
(lldb) r
error: process exited with status -1 (attach failed (Not allowed to attach to process.  Look in the console messages (, near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
--- End quote ---

Looking in the system log I find:

--- Quote ---macOSTaskPolicy: ( may not get the task control
port of (Calculator) (pid: 3441): (Calculator) is hardened, (Calculator) doesn't have
get-task-allow, ( is a declared
debugger( is not a declared read-only debugger
--- End quote ---

On the arm64e vs arm64 question, I compiled an Objective C application in Xcode 13.0 for Intel and M1 and it produces a universal binary with an ARM64 executable slice:

--- Quote ---trev@macmini8 [/Users/trev] $ file '/Users/trev/Library/Developer/Xcode/Archives/2021-09-22/RAM Monitor 22-9-21, 7.42 am.xcarchive/Products/Applications/RAM Monitor'
/Users/trev/Library/Developer/Xcode/Archives/2021-09-22/RAM Monitor 22-9-21, 7.42 am.xcarchive/Products/Applications/RAM Monitor: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
/Users/trev/Library/Developer/Xcode/Archives/2021-09-22/RAM Monitor 22-9-21, 7.42 am.xcarchive/Products/Applications/RAM Monitor (for architecture x86_64):   Mach-O 64-bit executable x86_64
/Users/trev/Library/Developer/Xcode/Archives/2021-09-22/RAM Monitor 22-9-21, 7.42 am.xcarchive/Products/Applications/RAM Monitor (for architecture arm64):   Mach-O 64-bit executable arm64
--- End quote ---


[0] Message Index

Go to full version