Andy, Thanks for the well-considered reply.
The bad thing that happens when Purify doesn't recognize something like this is that we fail to patch offsets to account for the code stretching we do. If something used to be 100 bytes away, maybe after Purify insertion it's 180, and we need to patch all offsets in relative computations that compute its address. In this case, the constant in the delay slot of the call to .PIC.me.up is a PC-relative offset, but we don't recognize it as such as we don't change it like we should. Thus the .PIC.me.up function doesn't compute its own address as intended, and the wrong addresses end up in out2 and global1. Then bad things happen later. (With luck, you crash; without luck, you silently get bad encryptions or decryptions.) Purify definitely does treat call8 specially: we know its behavior and its purpose, distinct from ordinary "call" instructions. Are you sure about call8 disrupting the retl prediction stack? I ask because it's such a common instruction in PIC code, you'd think the SPARC guys would know it's not really a call and wouldn't push to the stack when they see it. If the retl prediction stack problem is the only objection to using call8, I'd like to try to check this out. I don't know where to look for internal SPARC chip details like this, though. (I'm sure somebody on the PurifyPlus team does; I just don't happen to.) You are right that the top of .PIC.me.up is kind of similar to .LLGETPC0, but it's not similar enough. A sequence like this, using "sethi/call/add" that calls a "retl/add" stub to compute the GOT address, is squarely in the middle of our recognizer's green zone. Our analysis engine is tailored to recognize the PIC instruction patterns that come out of supported compilers - if it weren't, we wouldn't have a product. This does mean we need to rev PurifyPlus when compiler writers invent a new trick, but that's the life we lead. However, we can't recognize wide variations on these patterns, or recognize all possible combinations of instructions that could be used to produce a given effect. The universe of possibilities is just too big. I wouldn't mind a bit if you changed .PIC.me.up to use the same code sequence gcc uses to compute the GOT address, then reference those tables relative to the GOT. After all, you know Purify already recognizes that sequence. It's true that we could add a special pattern recognizer for .PIC.me.up after all... We'd still advise putting a comment in OpenSSL saying not to monkey with the call/add sequence lightly. That still seems fragile. I also don't advise a solution using something like "#ifdef PURIFY" because PurifyPlus users want to be able to Purify their code and yours without rebuilding your library in a special way. I didn't understand your question at the end about moving the last instruction of my new sequence. It restores the saved return PC from its temporary stash in g1 back to o7 where it belongs. I don't think that instruction can be moved. If you still have a question about that please try again. -- Allan Pratt, apr...@us.ibm.com Rational software division of IBM ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
