Duncan Sands
2011-Jun-14 17:27 UTC
[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
Hi Chris, I've CC'd Eric Botcazou in the hope that he will clear up just what the Ada front-end needs from the rest of the compiler as far as asynchronous exceptions are concerned.>> gcc Ada turns signals into exceptions. As far as I know it does this >> completely asynchronously, and the fact that LLVM doesn't support this >> is rather bad as far as Ada is concerned. That said, the Ada front-end > > You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals?AFAIK, on posix systems only SIGFPE, SIGILL, SIGSEGV and SIGBUS are turned into exceptions. For other signals, if there is no signal handler then the program is terminated; if the user installed a signal handler then it is run, and as far as I know there is no way for a user installed handler to raise an exception at the original point of execution without going deep into nasal demon territory. So SIGFPE, SIGILL, SIGSEGV and SIGBUS are the only ones that need to be thought about. I'm going to ignore the possibility that the user uses "kill" or somesuch to hit an Ada program with one of these signals. I think that falls out of the scope of the language standard, so any behaviour would probably be correct as far as the standard is concerned. For SIGILL, SIGSEGV and SIGBUS, I think the program has to be erroneous [*] to get one of these in the first place (note that null pointer dereferences and other things corresponding to "bounded errors" in Ada parlance [**] do not cause a segfault because the compiler inserts code to check for a null pointer before every dereference and explicitly raises an exception if the pointer is null), so I suspect that the compiler tries to do something (raise an exception) because it is helpful (quality of implementation) rather than because the language requires it. I wouldn't bet my life on this though :) As for SIGFPE, you will also never get this in normal usage (things like dividing INT_MIN by -1 never happen because the compiler inserts code to check for this before every division) and, based on the fact that the runtime doesn't even bother to attach a helpful message to the exception raised on SIGFPE, I'm not sure why the compiler even bothers with this one. In short, I think if LLVM ignores the possibility of signals being turned into exceptions then programs will probably still conform to what the language standard requires, but there might be some users complaining that stack overflow detection and recovery and other neat compiler features don't work when using LLVM as the GCC backend. But I don't know enough about this to be sure. Ciao, Duncan. [*] In C parlance, the program has undefined behaviour. [**] These are errors for which the consequences are carefully circumscribed by the language standard.
Chris Lattner
2011-Jun-14 22:38 UTC
[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
On Jun 14, 2011, at 10:27 AM, Duncan Sands wrote:> Hi Chris, I've CC'd Eric Botcazou in the hope that he will clear up just what > the Ada front-end needs from the rest of the compiler as far as asynchronous > exceptions are concerned. > >>> gcc Ada turns signals into exceptions. As far as I know it does this >>> completely asynchronously, and the fact that LLVM doesn't support this >>> is rather bad as far as Ada is concerned. That said, the Ada front-end >> >> You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals? > > AFAIK, on posix systems only SIGFPE, SIGILL, SIGSEGV and SIGBUS are turned into > exceptions. For other signals, if there is no signal handler then the program > is terminated;Ok, that makes sense. These are all synchronous signals, not asynch ones. -Chris
Eric Botcazou
2011-Jun-14 23:15 UTC
[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
> Hi Chris, I've CC'd Eric Botcazou in the hope that he will clear up just > what the Ada front-end needs from the rest of the compiler as far as > asynchronous exceptions are concerned.We actually support synchronous exceptions only. Just standard support for non-call exceptions (-fnon-call-exceptions) plus augmented unwind tables (-fasynchronous-unwind-tables) is required. Essentially like for Java.> For SIGILL, SIGSEGV and SIGBUS, I think the program has to be erroneous [*] > to get one of these in the first place (note that null pointer dereferences > and other things corresponding to "bounded errors" in Ada parlance [**] do > not cause a segfault because the compiler inserts code to check for a null > pointer before every dereference and explicitly raises an exception if the > pointer is null), so I suspect that the compiler tries to do something > (raise an exception) because it is helpful (quality of implementation) > rather than because the language requires it.A conformant Ada compiler is required to do stack checking (a few ACATS tests check it) and handle the Storage_Error. Of course you can implement it the way you like, but we try to do it properly on systems with MMU: probe the stack, hit the guard pages, catch the SIGSEGV and turn it into an exception that you can in turn catch. Needless to say, lots of gory details in there. -- Eric Botcazou
Duncan Sands
2011-Jun-15 13:06 UTC
[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
Hi Chris,>>>> gcc Ada turns signals into exceptions. As far as I know it does this >>>> completely asynchronously, and the fact that LLVM doesn't support this >>>> is rather bad as far as Ada is concerned. That said, the Ada front-end >>> >>> You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals? >> >> AFAIK, on posix systems only SIGFPE, SIGILL, SIGSEGV and SIGBUS are turned into >> exceptions. For other signals, if there is no signal handler then the program >> is terminated; > > Ok, that makes sense. These are all synchronous signals, not asynch ones.yes. Of course you can also send these signals asynchronously, but that's not why the Ada front-end is interested in them. Ciao, Duncan.
Seemingly Similar Threads
- [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
- [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
- [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
- [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?
- [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?