Search found 8 matches
- Sun Dec 22, 2019 10:04 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
SP points to the current position where last value was pushed. SP begins at the very bottom of the stack (so called SPUpper) and "grows" upwards. On 68k when a function is being called with stack parameters the stack inside the function will look like: SP+00 returnaddr SP+ 4 arg1 SP+ 8 arg...
- Sun Dec 22, 2019 9:55 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
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.But how exactly are they stored in the stack?
- Sun Dec 22, 2019 9:53 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
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.
Considering the authors of this project I am not even surprised.
Considering the authors of this project I am not even surprised.
- Sun Dec 22, 2019 9:25 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
They could be in stack yes. Doesn't AmiSSL document this stuff at all?
If they're in stack the process is a bit more involved (having to dig the values from array pointer by REG_A7).
Surely AmiSSL documents how the callbacks are being called?
If they're in stack the process is a bit more involved (having to dig the values from array pointer by REG_A7).
Surely AmiSSL documents how the callbacks are being called?
- Sun Dec 22, 2019 8:44 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
Or do we need a wrapper function like so: static LONG passwd_callback_wrapper(void) { char *buf = (void *) REG_A0; ... return passwd_callback(buf, num, encrypting, global_passwd); } static const struct EmulLibEntry FuncGate = {TRAP_LIB, 0, (void(*)(void))passwd_callback_wrapper}; ... SSL_CTX_set_de...
- Sun Dec 22, 2019 7:18 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
But how do I know which 68k registers the arguments are in then? Well AmiSSL documentation should specify that. If not, it's implicit (pointers get assigned address registers in order, integer types data registers). Any sensible API will have explicitly specified calling convention (ABI) though. No...
- Sun Dec 22, 2019 2:21 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
But before fixing this in hURL I'd need to know how to tell if AmiSSL is 68k or PPC. Maybe there's going to be a PPC native version of AmiSSL in the future and then this glue code of course mustn't be used. So how can I tell if AmiSSL is 68k or PPC? No you don't need to do any of that. The concept ...
- Sat Dec 21, 2019 11:01 pm
- Forum: General plugin questions
- Topic: hURL/AmiSSL crash on MorphOS
- Replies: 20
- Views: 16257
Re: hURL/AmiSSL crash on MorphOS
The bug is in hurl.hwp: It passes pointer to powerpc code for 68k callback. That is: When AmiSSL tries to call the callback, it will attempt to execute it as m68k code, leading to a crash. Disassembling the callback code in hurl.hwp that crashes gives us: 2B87 0007 move.l d7,$07(a5,d0.w) 9421 sub.b ...