> Do you have the possibility to help out with this? The help needed > would be to tell us exactly what assembler lines are incorrect,
It's not just a couple of lines that needs to be fixed up. Let's wonder first why are those routines implemented in assembler? Basically two reasons. To reach for hardware rotate instruction [or any other instruction not normally reachable from C] *and* [most improtant] to master register allocation. With latter I mean that compilers apparently don't do the job good enough to avoid/optimize register spilling which affects performance [most] *drastically*. In other words the idea behind those assembler implementations is pretty much to use up every damn register and it's really tight there. Now what would it take to PIC-ify the code? Most likely an extra register! The one you'll be calculating offsets from. And the problem is that there is no register to spare and if you're really up to it you might end up rewriting major portion of code! Which is why it's not necessarily trivial to PIC-ify the affected code. And it should be explicitely pointed out that the problem is so to say generic, i.e. all Intel platforms [not only Solaris, but as well Linux, *BSD, etc.] are affected. It's just that Solaris is the only one that brings the issue up. And what *is* the issue anyway? The issue is that non-PIC code in .so library so to say ruins the whole idea. It actually *works*, but the startup times are larger (run-time linker has to resolve those references at run-time) and the pages containing those references are not shared between processes and gets added up to the application footprint. But it *does* *work*... > so > we can hack the Perl code appropriately, or perhaps direct help with > said Perl code. > > A quick solution is to configure with no-asm... But the user has to understand that it will hurt the performance. Question is of course how much. Well, we can discuss it separately:-) > > Anyway, shared libraries with remaining text relocations are not > > really > > useful since they are not sharable, greatly diminishing their > utility. Not the whole thing is affected, only pages containing those unresolved references that become private. > The > > affected files during the Solaris 8/Intel compilation were > > > > crypto/bf/asm/bx86-sol.o > > crypto/cast/asm/cx86-sol.o > > crypto/des/asm/dx86-sol.o > > crypto/des/asm/yx86-sol.o > > crypto/md5/asm/mx86-sol.o > > crypto/rc4/asm/rx86-sol.o > > crypto/sha/asm/sx86-sol.o This is not true! Among listed modules only cast and des contain non-PIC. The rest is perfectly usable! Now cast is not really interesting and I find it hard to believe that anybody would miss the assembler implementation so that it probably should be just omitted [in shared context that is!] DES on the other hand is very popular and assembler implementation goes like 2-3 times faster so that I'd say it's essential to PIC-ify it. So that good news are that there is only one module that needs work. Bad news are that I've already challenged the community to fix it back in July 2001, but nobody has actually undertaken the effort. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
