Andy, I have been using 0.9.8h for my analysis, built for 64-bit. This is the same version the customer has. I also got 0.9.8j but it appears to have the same constructs. I don't know what's in the most recent sources.
Regarding load_n_bytes and friends, Purify *does* recognize the offset-based switch tables created by those macros, and we patch both the offset TO the table and the offsets IN the table correctly. This is a common pattern for compiler-generated switches, and this code matches the pattern closely enough that we handle it. And by the way, I notice that the macros use call8, despite any impact on retl prediction. About OpenSSL shipping libcrypto binaries: whether you distribute binaries or not, Linux distro people do. A Purify customer building against libcrypto can get the binary package "libssl-dev" to get the headers to build against it without ever building it from source. I'm hoping we can arrive at a place where that works for Purify customers. I see what you mean about the caller/callee relationship in the example you gave. If the caller uses call/add to do the call and also compute a pointer to data, and the callee only receives this as an ordinary pointer (not as the basis for further PIC computations), there's nothing interprocedural going on for Purify to have to recognize. Sadly, today's Purify does not handle this call/add pair for passing a pointer to nearby data. It's not impossible for us to add a recognizer for this pattern, but we don't have one now. You might suggest this optimization to the GCC people, too: it seems like a nice trick for passing one pointer to nearby data, a like printf format string. If the gcc people started using this we'd HAVE to recognize it. The "sethi/or/call8/add" sequence in your most recent attached patch does work: Purify correctly identifies this as a PIC-relative address computation into %g1, and it patches the constants so %g1 refers to the indented data table. The following "sub" into %o2 doesn't need patching because Purify doesn't change the distance between the two tables, but even if we did change that distance we would have patched that too. Since we also recognize the switch tables in load_n_bytes and friends, we might have a winner here. But I haven't thoroughly studied the newest sources plus your patch yet, just those specific elements. Oh, by the way: when Purify stretches code, we don't try to preserve alignment above what's needed for correct operation, so tables that start with directives like ".align 64" might not stay aligned. If that's just for cache-line efficiency, there's no problem, it'll just run slower. (And if you're using Purify, the performance ship has already sailed.) But if your algorithm relies on the low six bits of the address being zero, you'll lose. The same goes for all the align directives I see. I hope that's not a problem. Further thoughts? -- 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
