There's no specification how callback parameters should be stored

[afalkenhahn]

AmiSSL currently doesn't seem to specify how callback parameters are to be stored. For example, it's completely unclear how parameters should be passed to the callback function passed to SSL_CTX_set_next_proto_select_cb. My tests have shown that they seem to be passed on the stack but there really should be some specification. This is very important when it comes to define trap handlers for MorphOS, for example, to allow PPC native programs call into 68k AmiSSL and vice versa.

Also see this discussion.

[Futaura]

Unsurprisingly, Piru is incorrect in some of the things he says regarding this... It has always been the case, AFAIK, since even AmiSSL v1 (when it was compiled with SAS/C, now GCC since v4), that on 68k parameters for callbacks should all be placed on the stack which is the default calling convention of both SAS/C and GCC, at least. To place function parameters in registers, instead of on the stack, you have to explicitly tell the compiler to do so - things were simpler back then!

Perhaps we need to explicitly mention this somewhere, but in the absence of that, the common sense thing to do would to be assume the default calling convention used on a system.

Ideally we need a MorphOS port of AmiSSL v4, but nobody seems interested in completing it :-(. I know some preliminary work was done on it, but never finished. It would obviously outperform the 68k port running under emulation by a huge amount. For PowerPC builds callback parameters are placed in registers, as per usual in the System V ABI. There is a huge performance gain to be achieved with all the PowerPC and AltiVec asm optimisations supplied with OpenSSL.

[piru]

incorrect in some of the things

Having completely missed the gcc m68k era I admit I didn't think stack arguments would be the default. You learn new things every day it seems. That is I did not even check which compiler options were used to build the library. Which is something someone would have to do to figure out the calling convention. Since there is no documentation about this in AmiSSL... at all.

Perhaps we need to explicitly mention this somewhere

Having spent several hours of my precious time trying to sort out this due lack of documentation I'd say pretty much emphatic "yes" to this.

Ideally we need a MorphOS port of AmiSSL v4, but nobody seems interested in completing it :-(. I know some preliminary work was done on it, but never finished. It would obviously outperform the 68k port running under emulation by a huge amount. For PowerPC builds callback parameters are placed in registers, as per usual in the System V ABI. There is a huge performance gain to be achieved with all the PowerPC and AltiVec asm optimisations supplied with OpenSSL.

Luckily MorphOS applications have fully accelerated and super fast openssl built-in, with powerpc assembler and AltiVec acceleration, including the Odyssey web browser. There is also Reggae http class that does https transparently, without any need to interface with low level ssl library such as openssl.

Banging OpenSSL API directly is complicated and error prone. OpenSSL lacks many of the critical parts of the common code (such as AIA support, intermediate caching, hostname validation). No wonder there are multiple forks trying to sort out the mess. If I'd ever build a shared library it would attempt to remedy all these issues (I don't claim to have a magic bullet to fix all these issues, maybe some completely different and more complete SSL library would make more sense? Who knows). Existing applications depending on it can just link OpenSSL statically.

I consider AmiSSL legacy at best, for which m68k library will suffice. That being said, I don't object someone porting it, I just don't see the point myself.

Anyway, this is likely the amount of effort I'm going to spend on this topic here. If someone has something to say do it in direct email to me.