Before, this just crashed lli. Now, instead, SIGSEGV is intercepted and an error message is emitted.
*TODO: test on windows (the signal interface seems to be the same, but I haven't a machine to try on ATM.
Fixes https://llvm.org/bugs/show_bug.cgi?id=30650
Details
Diff Detail
Event Timeline
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.
tools/lli/lli.cpp | ||
---|---|---|
364 | SEGV can come from anywhere, not necessarily JIT'ed code. |
I don't see much value to installing a signal handler that exits. The kernel does that for you and even gives a helpful exit code that the shell will interprept and print "Segmentation fault" for you. This also fights with LLVM's existing pretty stack trace functionality.
SEGV can come from anywhere, not necessarily JIT'ed code.