Herbie Robinson via llvm-dev
2016-Jul-04 01:37 UTC
[llvm-dev] try/catch with std::errc::bad_address
I was curious how std::errc::bad_address was handled; so, I made up this test case (fault_test.cpp): #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? 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. 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; }
David Majnemer via llvm-dev
2016-Jul-04 03:52 UTC
[llvm-dev] try/catch with std::errc::bad_address
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>