[PATCH] D26809: [lli] Handle SIGSEGV in Jit'ed code more gracefully.

[Filipe Cabecinhas via llvm-commits]

filcab added a comment.

Replying to your email:

> As the only pieces of code we're interested into are the RunFunction()
>  bits, we can (maybe) move this logic to ExecutionEngine or delete the
>  signal handler via SIG_DFL after runFunction() is executed. How does
>  that feel?

Portability is the thing that will bite us here. If the systems "we care about" support `sigaction`, then we can save the old one when we install our handler. Then, on a handler call, we:
check if we're in JIT'ed code (is this feasible?)
If so, error and quit(?)
Else: forward to "old" handler (if there wasn't any, we'll probably abort anyway).

But given that this is for JIT'ed code, maybe we should go for less flexible and simpler: Have a way to have llvm *not* install a SEGV handler. If the program doesn't want us to handle, they can avoid it. Otherwise, they'll be stuck with us exiting the program.
Then, if someone files for additional features, we'll think about that and maybe accomodate.

I think the second, simpler, version might be best for now.



================
Comment at: tools/lli/lli.cpp:364
+  // in the main loop.
+  llvm::errs() << "SIGSEGV in JIT'ed code\n";
+  exit(1);
----------------
SEGV can come from anywhere, not necessarily JIT'ed code.


https://reviews.llvm.org/D26809