Problem when trying to debug with lldb on new arm64 M1

Question

Created Apr ’21

Replies 4

Boosts 0

Views 8.9k

Participants 4

Hi everybody,

I’m the maintainer of GNU Prolog (gprolog). I try to port it to the new arm64/darwin apple architecture since a contributor gave me an ssh access to its machine (I can thus only execute commands via command-line bash).

I can compile gprolog (it uses a classical unix-style procedure ./configure + make using gcc (clang)). The machine is pretty fast !

However, at run-time I obtain a segmentation violation which I’d like to debug using lldb. I initially obtained this error:

error: process exited with status -1 (developer mode is not enabled on this machine and this is a non-interactive debug session.)

I asked the owner of the machine to enable the developer mode. But now I obtain:

error: process exited with status -1 (this is a non-interactive debug session, cannot get permission to debug processes.)

I saw several posts mentioning entitlements (I’m sorry I’m not an expert of Mac). Here is what I obtain with my executable (I created a simple test case executable called ./t):

codesign -d -vvv --entitlements :- ./t
Executable=/Users/ddiaz/GP/src/BipsPl/t
Identifier=t
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=8410 flags=0x20002(adhoc,linker-signed) hashes=260+0 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=c0ddf4ad6672b7c65b2a90d274bb29783625d502
CandidateCDHashFull sha256=c0ddf4ad6672b7c65b2a90d274bb29783625d5021b6e1d67c6be5c7774c265b5
Hash choices=sha256
CMSDigest=c0ddf4ad6672b7c65b2a90d274bb29783625d5021b6e1d67c6be5c7774c265b5
CMSDigestType=2
CDHash=c0ddf4ad6672b7c65b2a90d274bb29783625d502
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

I saw, in some posts, a permission com.apple.security.get-task-allow which should be enable. Do you think the problem comes from this permission ? How can I add it using command-line console ?

Thanks you for your help

Didou

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’21

You should be able to set up a command-line build environment without GUI access to the machine. Here’s the process I used…

I set up a victim machine that had never seen Apple’s developer tools. This was a VM running macOS 11.1 (this is Intel, but I don’t believe that Apple silicon would change this story).

I used my main machine to download the Command Line Tools for Xcode 12.4 package from the Downloads area on the developer web site

Note Click More (at the top right) to get to the archive.

I copied the resulting disk image to the victim VM.

Code Block  % scp Command_Line_Tools_for_Xcode_12.4.dmg virtual-big.local.:

On the victim VM I mounted the disk image:

Code Block  % hdiutil attach Command_Line_Tools_for_Xcode_12.4.dmg

IMPORTANT I’m using an admin account here. If you don’t have an admin account, see below.

I then installed the package:

Code Block  % sudo installer -pkg /Volumes/Command\ Line\ Developer\ Tools/Command\ Line\ Tools.pkg -target /

I ran DevToolsSecurity to enable developer mode:

Code Block  % sudo DevToolsSecurity -enable
Developer mode is now enabled.

I created a tiny test tool:

Code Block  % cat > hello.c
#include <stdio.h>
int main(int argc, char ** argv) {
 printf("Hello Cruel World!\n");
 return 0;
}
^D
% clang -g -o hello hello.c

I ran it, just to make sure it compiled OK:

Code Block  % ./hello 
Hello Cruel World!

I then ran it under LLDB:

Code Block  % lldb hello
(lldb) target create "hello"
Current executable set to '/Users/quinn/hello' (x86_64).
(lldb) br set -n main
Breakpoint 1: where = hello`main + 22 at hello.c:3:3, address = 0x0000000100003f66
(lldb) r
Process 1951 launched: '/Users/quinn/hello' (x86_64)
Process 1951 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
   frame #0: 0x0000000100003f66 hello`main(argc=1, argv=0x00007ffeefbffa40) at hello.c:3:3
  1   	#include <stdio.h>
  2   	int main(int argc, char ** argv) {
-> 3   	  printf("Hello Cruel World!\n");
  4   	  return 0;
  5   	}
Target 0: (hello) stopped.
(lldb)

The above assumes you’re an admin user. If not, you can ask an admin user to run the commands that require sudo. That resolves most of the issues here, but there’s still one final niggle. At the last step you see this:

Code Block  % lldb hello
(lldb) target create "hello"
Current executable set to '/Users/mrgumby/hello' (x86_64).
(lldb) br set -n main
Breakpoint 1: where = hello`main + 22 at hello.c:3:6, address = 0x0000000100003f66
(lldb) r
error: process exited with status -1 (this is a non-interactive debug session, cannot get permission to debug processes.)
(lldb)

A quick trick to the DevToolsSecurity man page reveals that you have to be either a member of admin or _developer to use LLDB. If the machine admin won’t add you to the admin group you can ask them to add you to _developer. An easy way to do this is with this command:

Code Block  % sudo dseditgroup -o edit -a UUU -t user _developer

replace UUU with your user name.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

DidouDiaz OP

Apr ’21

Hi,

Adding the _developer group to my account solved the problem.

Thank you very much !

0

Answer 3

ccoussee OP

Feb ’24

Hi, I'm getting the same error: process exited with status -1 (this is a non-interactive debug session, cannot get permission to debug processes. when trying to debug an application remotely on a Mac Mini M1, using VS Code on a Windows 10 desktop.

This used to work perfectly when the Mac mini was running Ventura, but after upgrading to Sonoma, remote debugging fails with above error. To make it work before, I had to do the following steps:

sudo DevToolsSecurity -enable
spctl developer-mode enable-terminal
sudo dscl . append /Groups/_developer GroupMembership <myuser>
setup ssh connection via private/public key pair
installed CodeLLDB plugin in VS Code

Connecting to the Mac Mini with VS Code still works, applications are built on the Mac Mini, and do still run, just the remote debugging doesn't work anymore I looked at the steps described by @eskimo, and local debuiging using the command line lldb still works, so it's not entirely the same issue, though the error message is the same ...

Any feedback appreciated, Thanks,

Chris

0

Answer 4

ccoussee OP

Feb ’24

Interesting, I did install the CodeLLDB plugin in VSCode, because back then I couldn't get the remote debugging to work without it. So in the launch.json configuration I started using: "type": "lldb" because "type": "cppdbg" was not working.

Now I switched back to "type": "cppdbg" and it's working again ... Thanks,

Chris

0