[llvm-commits] CVS: llvm/Makefile.rules

[Reid Spencer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20060818/689dbabf/attachment.sig>