Hey Chris, It's been a few years since I've looked at/touched the verifier code, and one of the things I remember never ironing out was the exception-handling verification. I was working on the verifier as part of my senior thesis, and had a branched version that wasn't checked in that was verifying bytecode with a more expressive type system, so unfortunately didn't have the time to finish off all the features of a complete bytecode verifier.
After I graduated, Tom Tromey wrote a verifier in C++ for his gcj work, and then made it modular. A while ago we had spoken about integrating it with Kaffe, and I honestly believe that that's the way to go going forward, so if you're interested on working on the verifier I'd look Tom up. Alternatively, it probably wouldn't take too much work to get the existing verifier cleaned up and fully operational, and I'd be happy to check the code out again and give advise when you run into trouble, but I really do think that it's a good idea to be able to share the code for something as important and modular as a verifier between projects. -Rob On 12/21/06, Chris Gray <[EMAIL PROTECTED]> wrote:
Dear all, I've been studying the Kaffe verifier and I'm coming across cases of "either I don't understand this or it's wrong". I'm posting these here in the hope that somebody who understands the verifier (Rob?) will read them ... First, I see flags being tested in the 'status' field of a basic block which I only see being set in in the 'status' field of an instruction. Maybe somewhere flags are being copied from the first instruction of a bb to the bb itself, but if so I don't see it. Example: flag EXCEPTION_HANDLER is set for the instruction corresponding to handler_pc of an exception, but in verifyMethod3b() this flag is tested for a bb. Second, I don't see how transfer of control from code guarded to an exception handler to the handler itself is taken care of. As I understand it, the successors to an instruction include all the exception handlers which cover that instruction; working with basic blocks this should normally mean that (i) both the start_pc and end_pc of the exception should open a bb, and (ii) after evaluating a bb the resulting local vars need to be merged with those of all relevant exception handlers, not just the successor blocks reachable by "normal" execution. Either the code is smarter than I am, or this is not happening. All the best, Chris -- Chris Gray /k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 Note: we will closed for all but urgent support activities from Saturday 23 December 2006 to Monday 1 January 2007 inclusive. _______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
_______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
