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>
Well, I just discovered that there is logic in the Verifier with the AbortBroken flag that would prevent the abort. Unfortunately, there's no way to set it (anonymous namespace, hidden object instance) if you're calling verifyModule. Let me look at the code some more and think on this a bit. There has to be a solution that will make everyone happy :) Reid. On Thu, 2004-04-01 at 18:30, Reid Spencer wrote:> 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/e442c3c3/attachment.sig>
On Thu, 1 Apr 2004, Reid Spencer wrote:> 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.The verifier should provide two APIs: 1. The Verifier pass should do what it currently does: check the program and abort on failure. 2. There should be a VerifyModule function which checks the program and throws an exception on error with an error message. I would assume that this is the one you would want to use. I don't think that the verifier can actually emit multiple error messages. After it finds one problem, it can't really depend on the state of the module, so it bails out immediately. Throwing the exception would give the same semantics and allow the caller code to decide how to handle it... -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Thu, 2004-04-01 at 19:23, Chris Lattner wrote:> The verifier should provide two APIs: > > 1. The Verifier pass should do what it currently does: check the program > and abort on failure. > 2. There should be a VerifyModule function which checks the program and > throws an exception on error with an error message. I would assume > that this is the one you would want to use. > > I don't think that the verifier can actually emit multiple error messages. > After it finds one problem, it can't really depend on the state of the > module, so it bails out immediately. Throwing the exception would give > the same semantics and allow the caller code to decide how to handle it...The verifier can emit multiple messages of the same kind. For example, when it processes the list of functions, it processes them all and then aborts if it finds errors in that list. I've seen the output so this isn't creative thinking. So, I'm going to make verifyModule do as you mentioned. The messages will be gathered in a stringstream and thrown. 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/20040402/f94a0aef/attachment.sig>
P.S. Here's an example of verifier code that can emit multiple messages:
bool doFinalization(Module &M) {
// Scan through, checking all of the external function's linkage
now...
for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I)
visitGlobalValue(*I);
for (Module::giterator I = M.gbegin(), E = M.gend(); I != E; ++I)
visitGlobalValue(*I);
// If the module is broken, abort at this time.
abortIfBroken();
return false;
}
The function visitGlobalValue will check one value, print out a message
and set Broken=true. The abort doesn't happen until abortIfBroken() is
called.
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/20040402/23bd5e2f/attachment.sig>