Hi, Through some fat fingered typing of my own, I've run into some LLVM Verifier failures recently. I've noticed that the basic action the Verifier takes is to print some messages and then call abort(). The XPL Compiler is written as a compile server. It can take requests to compile multiple files from different sources. Therefore, abort() isn't particularly friendly in this situation. While I should write a compiler that doesn't fail verificiation, I'm also not perfect. So, I'd prefer it if there was a way to override this behavior. Would anyone mind if I changed the Verifier to allow installation of a failure handler function that defaults to abort()? I would also like to change the verifier to print to an arbitrary iostream instead of always to std::cerr. This will help me capture the verifier's output and produce it to the user within an "ICE" message. Again, the default would be std::cerr so if you don't use the new api, the current behavior is retained. Reid. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040401/39f8417b/attachment.html> -------------- 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-dev/attachments/20040401/39f8417b/attachment.sig>
On Thu, Apr 01, 2004 at 05:54:27PM -0800, Reid Spencer wrote:> Would anyone mind if I changed the Verifier to allow installation of a > failure handler function that defaults to abort()? I would also like > to change the verifier to print to an arbitrary iostream instead of > always to std::cerr. This will help me capture the verifier's output > and produce it to the user within an "ICE" message. Again, the default > would be std::cerr so if you don't use the new api, the current > behavior is retained.Perhaps another solution would be to throw an exception with the error message? -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
On Thu, 2004-04-01 at 18:04, Misha Brukman wrote:> Perhaps another solution would be to throw an exception with the error > message?Perhaps, but that would violate the programming contract already in place. Right now LLVM and its users expect failed verifications to cause an abort(). I wouldn't want to unleash on LLVM the new semantics of now handling exceptions in every place the verifier is called especially since the exception is basically saying "corrupt Module, use at your own risk". Additionally, exceptions can only throw single strings from single places but the verifier can actually generate multiple lines of output (from multiple checks) before deciding to abort. 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-dev/attachments/20040401/3108ff25/attachment.sig>
On Thu, 1 Apr 2004, Reid Spencer wrote:> compiler that doesn't fail verificiation, I'm also not perfect. So, I'd > prefer it if there was a way to override this behavior.Make sense.> Would anyone mind if I changed the Verifier to allow installation of a > failure handler function that defaults to abort()? I would also like to > change the verifier to print to an arbitrary iostream instead of always > to std::cerr. This will help me capture the verifier's output and > produce it to the user within an "ICE" message. Again, the default would > be std::cerr so if you don't use the new api, the current behavior is > retained.I think that the best solution would be to print to a stringstream and then throw the completed string as an exception. The default verifier pass would catch the exception, print it out, then call abort. Your hooks could do other things with the exception as you please. Does this make sense? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/