>>> 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*[!].
Well, this was not whole truth either: 0.9.8 tree had this offset data at mentioned location (as well as #ifdef OPENSSL_PIC), which I failed to remember. Sorry about confusion:-( See http://cvs.openssl.org/chngview?cn=17899 for 0.9.8 patch, which harmonizes modules in HEAD and 0.9.8 branches. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
