>> Further digging in des_enc.m4 revealed another problem. Besides the actual >> instructions in .PIC.me.up there is something else Purify doesn't notice >> that it should patch. The data item at .PIC.DES_SPtrans is the 32-bit >> offset from its own location (in .text) to DES_SPtrans (in .rodata). >> Because of code movement, Purify needs to patch this data item, but >> doesn't notice that it should. (Once again, this is a nonstandard way for >> a program to get the address of a data item in a position-independent >> way.) > > ??? Latest version of des_enc.m4 does not have any offset data.
This is incorrect statement. Latest version of des_enc.m4 does not have offset data at *mentioned locataion*[!]. I mean it's not like it doesn't have *any* offset data whatsoever. Because there *is* offset data in dispatch table for switch-like code, see load_n_bytes macro. Would Purify be able to handle this one? Well, given that you could assert that your original code modification to .PIC.me.up did the trick, but could you have a look at the macro in question anyway? What build did you test, 32- or 64-bit one? Or only one, see if it works in another context as well... A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
