LLDB doesn't stop on SIGABRT (assert) with x86 executable on Apple ARM

I was trying to debug a x86_64 executable on my new Apple silicon and noticed it wouldn’t stop on asserts. See below 2 runs of a small Hello world compiled and run with arch x86 and then arm64. Is it an expected, known issue, if yes would you know of any workaround?

   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                               14:46:01
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (x86_64).
(lldb) r
Process 12031 launched: '/Users/flr03/Workspace/untitled' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12031 exited with status = 6 (0x00000006) Terminated due to signal 6
(lldb) q
   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                        21s   14:46:31
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (arm64).
(lldb) r
Process 12077 launched: '/Users/flr03/Workspace/untitled' (arm64)
Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12077 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #4: 0x0000000100003154 untitled`main at main.cpp:10:5
   7   	{
   8   	    cout << "Hello World!" << endl;
   9
-> 10  	    assert(0);
   11
   12  	    return 0;
   13  	}

If you watch the gdb-remote packet logs for the two sessions, you will see that in the Rosetta2 run, lldb is never told about the signal, the process just dies out from under us whereas in the AS native run, we get an EXC_SOFTWARE/EXC_SOFT_SIGNAL exception for the SIGABRT. This seems to be a problem with the Rosetta runtime. If you are interested in following up on this, please file a bug with Apple’s bug reporter (https://feedbackassistant.apple.com).

Jim

On Apr 4, 2023, at 7:02 AM, Florent R. via LLVM Discussion Forums notifications@llvm.discoursemail.com wrote:

GreatTux
April 4

I was trying to debug a x86_64 executable on my new Apple silicon and noticed it wouldn’t stop on asserts. See below 2 runs of a small Hello world compiled and run with arch x86 and then arm64. Is it an expected, known issue, if yes would you know of any workaround?

   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                               14:46:01
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (x86_64).
(lldb) r
Process 12031 launched: '/Users/flr03/Workspace/untitled' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12031 exited with status = 6 (0x00000006) Terminated due to signal 6
(lldb) q
   ~/Workspace ❯ lldb ~/Workspace/untitled                                                                                        21s   14:46:31
(lldb) target create "/Users/flr03/Workspace/untitled"
Current executable set to '/Users/flr03/Workspace/untitled' (arm64).
(lldb) r
Process 12077 launched: '/Users/flr03/Workspace/untitled' (arm64)
Hello World!
Assertion failed: (0), function main, file main.cpp, line 10.
Process 12077 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
    frame #4: 0x0000000100003154 untitled`main at main.cpp:10:5
   7   	{
   8   	    cout << "Hello World!" << endl;
   9
-> 10  	    assert(0);
   11
   12  	    return 0;
   13  	}


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

1 Like