Tracing of callhookpkt()/callhook()

PS. Also, did i understand it correctly, that they (os4 devs) tried to get rid of Varargs functions mostly from API ? Why i ask about, is that they say there https://wiki.amigaos.net/wiki/Linker_Libraries , that:

Intuition
CallHook() and CallHookA()
These functions invoke hooks. CallHook() expects a parameter packet ("message") on the stack, while CallHookA() takes a pointer to the message.
Replaced by IUtility->CallHookPkt() in V50.

Like, both were deprecated in favor of single CallHookPkt() , so to not have varargs function. Even if they have CallHook() still in utility.library (probably side effect of easy porting from os3 back in times), it all looks like that they want to get rid of Varargs one. Maybe because Varargs ones is potetialy not safe-ones, as can corrupt the stack in some conditions , etc, and that is the reassons they want non-varargs one to be used always ?

It's most likely not related to varargs at all, but that only utility.library CallHookPkt() includes the required check and different way to execute the Hook function depending on if it's emulated m68k code or PPC native code.

Varargs throws out a lot of type-safety - you could pass pointers, floats, etc., instead of ints and it will compile without issue. Misuse of varargs, such as omitting arguments, can introduce odd crashes due to stack corruption, or reading invalid pointers.

The vararg mandates that the parameter be passed on the stack, thus slowing the function call. On some architecture the difference can be significative. On x86 it's not very important because of its lack of register, on SPARC, for example, it can be important. Up to 5 parameters are passed on registers and if your function uses few locals, no stack adjustment is made. If your function is a leaf function (i.e. doesn't call another function), there is no window adjustment also. The cost of the call is therefor very small. With a vararg, the normal sequence of passing parameters on the stack, stack adjustement and window management is made or your function wouldn't be able to get at the parameters. This increases the cost of the call significantly.

A function using varargs cannot correctly verify its arguments

To try to avoid this, creators of varargs routines rely on conventions to manage this. For example, args sometimes get passed in as pairs - a type constant followed by the actual value ending with a sentinel:
SomeFunc(kInt, 3, kDouble, 2.0, kString, "blah", kLastArg);
Other times a descriptor is passed in first which describes the arguments:
printf("%d %f %s\n", 3, 2.0, "blah");
Other times, the first argument is a command:
DispatchMessage(kPaintWindow, &bounds, blackColor);
No matter what, it is possible to break the callee by passing in something that doesn't follow the convention. The problem is that there is nothing that can be done to enforce the convention. Without enforcement, you get a crash if you're lucky. If you're not lucky, you get a time bomb set in your heap that will go off only if the conditions are right.
In the last example, you're about as safe as you can get as long as you don't actually called DispatchMessage(), but instead use author-supplied macros like:
#define PaintWindow(bounds, color) DispatchMessage(kPaintWindow, bounds, color)
because then at least DispatchMessage is called correctly as long as the macro matches convention, and it is a single point of failure (which means a single point for a fix, which we like). I would turn around and argue that a single API, DispatchMessage, would be better off being multiple APIs.
Here's the skinny - if you're using varargs, you're probably doing something wrong out of the gate. Varargs promises a lot, but delivers very little.

But as they have both CallHookPkt() (non varargs) and CallHook() (varargs) different implementation even today in utitlity.library, it's interesting why they choose to expand with emulator check an CallHookPkt() and not CallHook().

The removed amiga.lib/libamiga.a CallHook() didn't support emulated m68k code, but of course the utility.library one does.

OS4 devs says that in OS4, CallHookPkt() and CallHook() are 2 independent functions.

On PPC nobody is using an asm stub in h_Entry and a C function in h_SubEntry. It's not required because on PPC all 3 arguments are passed in registers (r3, r4 and r5) in C code anyway.

On m68k an asm stub in h_Entry can be used which pushes the 3 registers A0, A2 and A1 on the stack and calls a C function in h_SubEntry. On m68k C functions don't use registers but only the stack for the arguments.

But even on m68k most people didn't use that anymore but something like

The EmulateTags() call works in any case, no matter if there is a m68k asm stub in h_Entry which calls a h_SubEntry function with stack arguments, or if h_Entry is the C function using register arguments with the REG() macro.

It's the same for PPC native code, just in case someone uses useless code like

The 68K ABI convention is also the same way as the native ABI also uses registers in API calls,

Quote:
But even on m68k most people didn't use that anymore but something like

Except in that case but it can be compiler specific.

No, it doesn't.

It would have been compiler specific if I'd have used something like

That's still too complicated. Given a library call is like this without needing to think about it.

So it certainly could have been programmed in.

int32 hookFunc(struct Hook *hook, APTR object, APTR message)

Only works because on m68k the AmigaOS library calls are replaced with inline functions, macros or #pragma, depending on the compiler, which replace the standard stack based m68k ABI with register arguments, and a hidden A6 library base argument, for those functions .

Regarding SDI, looks like it was a bit too late for the 80's, being dated from this century.

But what does SDI mean? I read through that project years ago and unless I missed the obvious it doesn't say what it is. I think an acronym is rather pointless if it isn't explained on the first line of the readme.

Are you sure IUtility->CallHook() doesn't include m68k support?
That would be very strange.

For AmigaOS, 1-3.x/m68k and 4.x/PPC, it's useless, the REG(), ASM, SAVEDS, etc. macros are enough if you want to support both m68k and PPC versions of AmigaOS, or even just different compilers: SAS/C, DICE, StormC, VBCC and GCC for m68k AmigaOS, VBCC and GCC for PPC AmigaOS. SDI is only required if you additionally want to support AmigaOS incompatible OSes like AROS and/or MorphOS.

Standard Developver Interface

Do some debugging with GDB and find out that even for IUtility->CallHook(.....) there seems to be 68k emulator check too (while, it different functions still, and not simple use of CallHookPkt() inside), see:

And as far as i aware, this function checks whether a pointer points to a segment containing PPC-native or 68k code. The segment is determined by the most significant 4 bits of the address, which is then used as an index into a table. The type read from this table is 0 for 68k code and 1 for PPC code. When a 2 is read, then the BAT registers decide about the type of code and go back to callhook().

Exactly the same code present in the CallHookPkt() too, so they both seems to call some internal function which do that check, something like "is_hal_native()" or something of that sort.