I don't see any of this documented in AmiSSL. Only the register convention of the LVOs is obviously documented. For callback functions I see no such specification.
But since the parameters aren't in the registers, they surely must be on the stack. But how exactly are they stored in the stack? I've tried to look for the "arg" parameter (the last callback parameter) like this:
Stack grows upwards (pushing values to stack makes stack pointer get upwards in memory). So any parameters that might be there are on the positive side.
Piru wrote: ↑Sun Dec 22, 2019 9:53 pm
It seems AmiSSL doesn't specify the calling convention. In fact, it depends on the compiler specifics (gcc in this case). What a horrible design.
Well, another reason for MorphOS team to come up with an in-house solution that uses a clear specification
Piru wrote: ↑Sun Dec 22, 2019 9:55 pm
Stack grows upwards (pushing values to stack makes stack pointer get upwards in memory). So any parameters that might be there are on the positive side.
Of course all this is also complicated by the fact that you can have part of the arguments in registers and ones that didn't fit in stack. And lets not get into varargs. Lets hope we don't need to worry about those.
Last edited by Piru on Sun Dec 22, 2019 10:14 pm, edited 1 time in total.
How about linking OpenSSL statically to the hURL plugin for MorphOS? hURL has different requirements for different platforms anyway, so maybe it could be ok?
We would avoid 3rd party requirements then... and it seems that AmiSSL v4 installer doesn't work properly with MorphOS Installer either... I'd have to examine that more closely some day, but it seems to fail to add the required lines to the S:user-startup. I didn't notice this earlier when updating old AmiSSL with existing assigns, but doing that on a fresh system seems to fail.
jPV wrote: ↑Mon Dec 23, 2019 8:58 am
How about linking OpenSSL statically to the hURL plugin for MorphOS? hURL has different requirements for different platforms anyway, so maybe it could be ok?
This would bloat hurl.hwp to a 5MB+ binary that is loaded with the start of every Hollywood app. Not something very desirable IMHO...