[llvm-dev] try/catch with std::errc::bad_address

[David Majnemer via llvm-dev]

On Sun, Jul 3, 2016 at 6:37 PM, Herbie Robinson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I was curious how std::errc::bad_address was handled; so, I made up this
> test case (fault_test.cpp):
>

The std::errc::bad_address code maps to POSIX EFAULT.  The intent behind
its existence is to inform user code that a system call was passed a bad
address.  Nowhere in the default stack of software a mechanism to
automatically transform faults into exceptions of type 'std::system_error'.


>
> #include "fault_test.hpp"
> #include <exception>
> #include <system_error>
>
> static int n;
>
> void fault_test(int *p)
> {
>   std::error_code ec = make_error_code(std::errc::bad_address);
>   std::system_error e = std::system_error(ec);
>
>   try
>   {
>     n += *p;
>     std::cout << "No fault.\n";
>   }
>   catch(const std::system_error &e)
>   {
>     std::cout << "Caught the fault.\n";
>   }
> }
>
> int get_sum(void)
> {
>   return n;
> }
>
> The fault isn't caught by the catch clause, It just faults in the try
> compound_statement (running it under Xcode).  Thinking about this a little
> bit, I can see why anything implementing unwinding using the GGC algorithm
> would decline to implement this (because the exception usually wouldn't be
> handled and that would be pretty rude debug behavior).
>
> I was wondering if:
>
> 1,  The Windows SEH algorithms can handle this?
>

SEH can handle this with __try/__except but the exception has to be thrown
from a call (use noinline on the callsites in the __try block).

Things get super weird with optimization regardless of inlining (e.g. non
volatile loads and stores which commit UB can be removed in call sites
inside the try which would result in the __except block not running).


>
> 2.  LLVM is prepared to handle exceptions arising out of anything that
> happens in the try compound statement or only calls?
>
> The reason I ask is that other OSes that one might port to do support
> catching general faults in their unwind mechanisms.  I believe Multics
> implemented that in pl1 way back when:  The idea is to keep your kernel
> gates as fast as possible by just making sure output arguments point at
> things the user is allowed to modify and letting the exception handler
> catch faults arising from bad reads.
>

In LLVM, only calls are candidates for throwing.  We don't support
GCC-style -fnon-call-exceptions.


>
> The other files for the test:
>
> fault_test.hpp:
>
> #include <iostream>
>
> extern void fault_test(int *p);
> extern int get_sum(void);
>
> main.cpp:
>
> #include "fault_test.hpp"
>
> int main(int argc, const char * argv[]) {
>   // insert code here...
>   fault_test(nullptr);
>
>   std::cout << "Sum = " << get_sum() << "\n";
>     return 0;
> }
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160703/1906645f/attachment.html>