Question

Context: I am programming an interpreter for another platform, and this means that often, my program will load pointers from arbitrary integer data. When it comes to branches, I try to dereference for reading the next instruction’s address immediately, so that if the address is invalid, I get the segmentation fault inside the branch instruction’s method, and not some time later. This should make debugging easier.

However, this is not as helpful as I would have hoped for. When a segfault occurs there, it should be completely recoverable, since it was triggered by a dummy read, so I would like to be able to move the program’s instruction pointer back to the beginning of the method and reset the segfault.

Can I tell LLDB to ignore a SIGSEGV that has already made it to my program? I know that I can use process handle ... to decide which signals make it to my program, but that does not apply to signals the process is currently handling (or rather not handling).

(If it is not possible, I guess I could still ask lldb to stop on segfaults and not pass them to the program, but I’d at least like to know if it’s possible or not.)

Answer 1

I think you’re trying to work around an EXC_BAD_ACCESS to put it properly. For instance, it sounds like you’re describing the dataptr in this example program

#include <stdio.h>
int main ()
{
  void (*funcptr)(void) = 0;
  int *dataptr = 0;
  puts ("about to deref dataptr");
  printf ("%d\n", *dataptr);
  puts ("about to call through f ptr");
  funcptr();
  puts ("done");
  return 0;
}

You’ll hit the first EXC_BAD_ACCESS on the dataptr dereference in the printf call. You can change the variable to a valid value to continue execution. The one trick here is that the variable dataptr lives on the stack in my -O0 compiled example, so you need to set the register that is being read at this point to get past it. Here I just use the start address of main() as a valid address in this program as a simple example.

* thread #1: tid = 0x1f03, 0x0000000100000eb6 a.out`main + 54 at a.c:7, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
-> 7      printf ("%d\n", *dataptr);

(lldb) disass -c 1 --pc
a.out`main + 54 at a.c:7:
-> 0x100000eb6:  movl   (%rcx), %esi
(lldb) reg read rcx
     rcx = 0x0000000000000000
(lldb) p dataptr
(int *) $0 = 0x0000000000000000

(lldb) p dataptr = (int*) main
(int *) $1 = 0x0000000100000e80
(lldb) reg write rcx `$1`

(lldb) c
Process 77491 resuming
-443987883
about to call through f ptr
* thread #1: tid = 0x1f03, 0x0000000000000000, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    #0: 0x0000000000000000

Now I’m stopped because I called through a NULL function pointer. Unwinding this takes a little extra x86_64 ABI knowledge but it’s not all that hard — set the pc to the caller’s return address, pop the stack one word and you’re back.

(lldb) reg write pc `*(unsigned long long *)$sp`
(lldb) reg write sp `$sp + 8`
(lldb) c
Process 77522 resuming
done
Process 77522 exited with status = 0 (0x00000000) 

of course this is very by-hand tweaking here – not so easy to automate. You could express the null function pointer deref with a python function and add an lldb command to do it easily, but the null data pointer deref requires that you know what register was being accessed – maybe some clever pattern matching of the disassembly instruction could do the same thing with some python extension for common cases.

Hope that helps.