On Fri, 2006-08-18 at 10:04 -0700, Chris Lattner wrote: > On Aug 18, 2006, at 9:55 AM, Reid Spencer wrote: > > Hmm .. didn't think of that, but it passed all the tests. All the > > tools > > still have top level exception handlers so its not like we'd > > generate an > > unexpected_exception error. Some memory cleanup could be missed, > > but the > > process is going to exit anyway. Temporary files that need to be > > cleaned > > up are generally done in the tool's code, so that should be okay. What > > else could go wrong? > > Consider: > > "main" has a catch block, which prints an error message and exits. > main calls foo. > > "foo" is compiled without exception info, foo calls some llvm::sys > function 'X' that can throw. > > "X" throws an exception on some error. > > We'd expect the exception to end up in main, an error printed, then > the process exited. However, because "foo" has no unwind info, the > unwinder will abort the process when it gets to the X frame.
I was under the impression that those stack frames would just get bypassed. However, I wrote a little test program to simulate the situation and got: terminate called after throwing an instance of 'std::string' Aborted So, I'll back out the change until we get LLVM completely EH free in low-level libraries. > > I think the simplest thing to do is to eliminate throws from leaf > code like libsystem etc. Tools like bugpoint can continue to use EH > for as long as we think is reasonable, but the libraries that are > called into by other code should be EH free. Yes, that's the entire point of PR797. I was just trying to be incremental about it. Reid.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
