[LLVMdev] aborting on invalid code
Vikram S. Adve
vadve at cs.uiuc.edu
Mon Oct 13 13:56:35 PDT 2008
On Oct 13, 2008, at 3:16 PM, Chris Lattner wrote:
> On Oct 13, 2008, at 1:10 PM, Robert Zeh wrote:
>> On Oct 13, 2008, at 1:07 PM, Chris Lattner wrote:
>>> Exceptions have a high cost in terms of code size, binary size, and
>>> even a bit of execution time.
I agree. I think the client should be allowed to choose whether to
compile these in or not. At the LLVM library level, this may have to
be compile-time selected (which could be a bit ugly but should not be
too bad) to avoid the code size problem.
>>> Also, they don't magically make the
>>> code safe from any error: code has to be designed specifically to
>>> RAII and other techniques to handle exceptions properly.
I understand that -- you're not making the client's life easy, you're
just making it possible.
>>> Reading a
>>> + trade magazines/books about EH topics will give you an idea of the
>>> complexity involved in doing it right. Further, as I mentioned up-
>>> thread, turning aborts into exception throws won't save you from
>>> pointer or garbage pointer dereferences.
>> You can catch the null pointer and garbage pointer dereferences
>> with a
>> signal handler (in Linux land, at least), and then invoke your direct
>> reporting mechanism with that. Is the concern that some of the other
>> LLVM clients don't have signal handling?
> Garbage/dangling pointers can corrupt memory, they don't always trap.
> C just isn't a safe programming language (though there are many
> interesting research projects that can help).
Yes, but that's a case that LLVM would not do any error reporting
anyway. In any case, where it would otherwise report an error, it
seems to me you could give the client the *option* to handle the
signal and throw an exception, if needed, and then field the exception.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev