On Sep 8, 2008, at 4:30 PM, OvermindDL1 wrote:>> The Verifier pass is recommended; it catches a lot of >> invalid stuff and be configured to abort, print an error to >> stderr, or return an error status and message string. >> >> It doesn't catch everything though; codegen's error >> handling today is usually an assertion failure, assuming >> assertions are enabled. > > Was looking through some other code in LLVM, I noticed an abort(), how > often do those occur as they would be *really* bad to occur in my > circumstances (the couple I saw were in the JIT class) as catching the > abort signal may not always be possible depending on the hosts code. > > Will the verifier catch things like integers that are too big for the > platform that I am currently on, or will that be done by something > like the JIT when it compiles it?No, the verifier currently does not know about target-specific codegen limitations.> > And yea, assertions are a very large "no" in this library, especially > since bad code will probably happen very oftenPatches to do the kind of checking you're asking about would be welcome :-). I don't think it makes sense to extend the Verifier itself here; it's supposed to accept any valid LLVM IR. I think a separate CodeGenVerifier might be a good approach though, or possibly extending codegen itself with the ability to interrupt itself and yield some kind of error status. Dan
> Patches to do the kind of checking you're asking about would be > welcome :-). I don't think it makes sense to extend the > Verifier itself here; it's supposed to accept any valid LLVM IR. > I think a separate CodeGenVerifier might be a good approach > though, or possibly extending codegen itself with the ability to > interrupt itself and yield some kind of error status.And I presume you all are allergic to exceptions, since I have seen none so far (probably due to help the C bindings and such), return error codes all over the place then? If I do any extension on this (short on time, so good chance I cannot, but if I do) the usual non-exception style I use is the return value is a status code, the last argument passed in is an optional std::string* (the return code gives the basic error reason, the string gives details), anything that actually needs to be returned are the first arguments as references/pointers, would that work?
Do note though, that would cause an interface breaking change (just in the function signatures, but still). An alternate would be to just pass in a struct that the user can subclass to perform their own error reporting, call a certain function in it or so before it finally bails out, it puts a level of indirection so if someone wants to recover they will have to use their own variables stored somewhere, so it is much more ugly and would not work well with C style bindings, whereas the interface breaking change would. Or are there any other styles that are preferred? On Mon, Sep 8, 2008 at 8:08 PM, OvermindDL1 <overminddl1 at gmail.com> wrote:>> Patches to do the kind of checking you're asking about would be >> welcome :-). I don't think it makes sense to extend the >> Verifier itself here; it's supposed to accept any valid LLVM IR. >> I think a separate CodeGenVerifier might be a good approach >> though, or possibly extending codegen itself with the ability to >> interrupt itself and yield some kind of error status. > > And I presume you all are allergic to exceptions, since I have seen > none so far (probably due to help the C bindings and such), return > error codes all over the place then? If I do any extension on this > (short on time, so good chance I cannot, but if I do) the usual > non-exception style I use is the return value is a status code, the > last argument passed in is an optional std::string* (the return code > gives the basic error reason, the string gives details), anything that > actually needs to be returned are the first arguments as > references/pointers, would that work? >