But when i run my test binary, it simply invokes one time call to CallHookPkt when reach a state of "stricmp" comparison that it's my binary i want to trace, and then nothing happens : test binary with CallHookPkt usage didn't runs, but also didn't crash , and in trace we stuck forever on SuspendTask.. right when we should obtain a stacktrace. Maybe i can't suspend process like that ? I mean: SuspendTask(&process->pr_Task,0) ?
ps. Btw:
Quote:
I would have expected much more calls/s. layers and graphics (for example the BackFill Hooks), intuition (incl. all BOOPSI gadgets, images and data types, Windows alpha/shape/scrolling/etc., ...), IIRC Dockies (AmiDock) as well, and a lot more in AmigaOS uses Hooks
With AmiDock's Dockies there indeed lots more CallHookPkt() happens: 250/s (while without, with pure plain system with WB loaded only 50/s).
As for other intuitions and co hooks, it surely shows me just about 50/s. If you had access old source code of OS4, will it be no NDA-breaking if you will check if for example, those gadgets and datatypes you mention do use CallHookPkt(), or, still old CallHook() ?
And interesting, that when i tried to trace for example this one: https://www.os4coding.net/sites/default/files/ra_appwindow_0.txt (creates AppWindow hook in the ReAction window object) it counts ~500 calls to CallHookPkt(). So maybe if i not use any class when load up system, then it didn't loaded up, so those CallHookPkt() isn't active. But once i load up first time a app which use intuition hooks, then it throw massive usage of the CallHookPkt() ?
ps2: And if there is a way how we can calculate pure CallHook() usage (not CallHookPkt()) in whole system per second ? As far as i aware CallHook() were varags version of CallHookPkt(), so then finally any call to CallHook() go through CallHookPkt anyway..
Edited by kas1e on 2024/5/4 4:44:23 Edited by kas1e on 2024/5/4 4:57:21 Edited by kas1e on 2024/5/4 4:58:19 Edited by kas1e on 2024/5/4 5:34:51 Edited by kas1e on 2024/5/4 5:51:33 Edited by kas1e on 2024/5/4 5:55:28
But when i run my test binary, it simply invokes one time call to CallHookPkt when reach a state of "stricmp" comparison that it's my binary i want to trace, and then nothing happens : test binary with CallHookPkt usage didn't runs, but also didn't crash , and in trace we stuck forever on SuspendTask.. right when we should obtain a stacktrace. Maybe i can't suspend process like that ? I mean: SuspendTask(&process->pr_Task,0) ?
struct Process *process = (struct Process *)IExec->FindTask(NULL);
...
IExec->SuspendTask(&process->pr_Task,0);
You are suspending your own task, the one executing this code, and
uint32 result = IDebug->StackTrace(&process->pr_Task,hook);
IExec->RestartTask(&process->pr_Task,0);
can't be reached
Quote:
If you had access old source code of OS4, will it be no NDA-breaking if you will check if for example, those gadgets and datatypes you mention do use CallHookPkt(), or, still old CallHook() ?
I don't have access to the sources, but using m68k libamiga.a CallHook() in PPC native code is impossible. It can only be used for emulated m68k hook functions called by emulated m68k code, only IUtility->CallHookPkt() can be used from PPC native code, checks if the hook function is PPC native (direct function call) or emulated m68k code (executing it with the m68k emulator).
Is there an OS4 PPC libamiga.a with a CallHook() function? Would be complete nonsense (unless all it does is calling IUtility->CallHookPkt()), but OTOH I wouldn't be surprised if clib2 has something like that.
Quote:
And if there is a way how we can calculate pure CallHook() usage (not CallHookPkt()) in whole system per second ?
CallHook() is no OS function but statically linked into m68k executables from the m68k libamiga.a, some implementations of libamiga.a CallHook() are even m68k assembler.
You are suspending your own task, the one executing this code, and
Damn :) But if i will remove suspend/restart, i then will be not able to correctly obtain stack trace ? (tried now with removing, crashes on IDebug->StackTrace(..) )
Quote:
Is there an OS4 PPC libamiga.a with a CallHook() function? Would be complete nonsense (unless all it does is calling IUtility->CallHookPkt()), but OTOH I wouldn't be surprised if clib2 has something like that.
Clib2 indeed have amiga_callhook.c and amiga_callhooka.c:
But this one compiles in only when build 68k version of clib2, for os4 it didn't (at least, as i see from Makefile's in Andrea's clib4 fork). But if i check libamiga.a from original clib2, i can see there "amiga_callhooka.o", which probabaly just an empty stabs, as code of CallHookA pure 68k asm.
Quote:
CallHook() is no OS function but statically linked into m68k executables from the m68k libamiga.a,
Right, so then we can forget about CallHook() old stuff then. Probably the reasons why i have so small amount of CallHookPkt() calls on pure WB (50/s), is that nothing were runs which open up hooking functionality of all classes,libs,etc (through, i was under opinion that when WB load up, it already uses intuition heavy).
You are suspending your own task, the one executing this code, and can't be reached
But aren't i doing this only when i am in process which had cli_commandname i point out in the argv[1], so should suspend this one instead, and not my general one ?
In other words, how to find out an task address of the process i need to trace, like by doing another FindTask ? But how to say that this is the task i need to find which had my cli_commandname ? The task name my binary have is "Background_CLI" as many other ones, so second FindTask() probably will of no help there (that why i were under impression that when i am already checked that current process is the one having my cli_command, doing suspend of this process will mean suspend this one, and not general one).
I can see what's going on. Your patch does indeed find the process that is calling your patched function and is a different process to your tracing process. The problem is when another process calls your function that process is the one running so it ends up suspending itself!
You will need to do some IPC I think. I've dealt with this stuff before. What I usually do is setup a MsgPort stored as global pointer in main process so it can be reachable outside it. Then in the patched function setup a Message as local static or allocated on demand. Fill it with the task ID. Send it to your main process and wait. From the main process wait on the port for messages. Perform the needed extraction, print it out then signal back. I like to use SIGF_SINGLE as it's designed for one time use. It should be cleared beforehand.
This way also avoids suspending a task as the other task will be waiting for your main one to process the information. Then it gets signalled back. Given it needs to print out a stack track regardless the latency of using IPC shouldn't bother it much.
The problem is when another process calls your function that process is the one running so it ends up suspending itself!
mm.. sounds complicated enough ! :) I mean we run the binary, so we have our own findtask(NULL) process (of main binary, in the main() ).
Then, if we run findtask(null) in the patched callhookpkt(), then we find the proccess from where this patched callhookpkt were run, right ? (because if not, how i can detect then the name of the tasks invovled in, etc).
And then, when we in this process in this patched function, should't process be not our from main(), but the one name of task from which we are taken ?
mm.. sounds complicated enough ! :) I mean we run the binary, so we have our own findtask(NULL) process (of main binary, in the main() ).
The fun of library patching.
But I don't see FindTask(NULL) in your main(), I only see it in the Patched_CallHookPkt() routine.
Quote:
Then, if we run findtask(null) in the patched callhookpkt(), then we find the proccess from where this patched callhookpkt were run, right ? (because if not, how i can detect then the name of the tasks invovled in, etc).
Yes, the process that called CallHookPkt(). It would find that process in FindTask().
Quote:
And then, when we in this process in this patched function, should't process be not our from main(), but the one name of task from which we are taken ?
Yes, it would. That's where I see the issue. The process that called Patched_CallHookPkt() would end up suspending itself. Since it finds itself with FindTask(). Then passes that to SuspendTask(). It finds itself then loses itself lol.
It likely doesn't matter what context printStack() would be running in at this point. If printStack() is running on the same context as the calling process, that is while it's the running process, then that will cause trouble.
However, looking again at the code of callhookpkt_stacktrace_v1.c, this may be easier than it seems. Is this libauto as no libraries are opened? Also, where is IDebug filled in? I don't see any protos for it nor am aware of libauto able to open debug interface of Exec.
But I don't see FindTask(NULL) in your main(), I only see it in the Patched_CallHookPkt() routine.
Rigth, there is none, because i don't it :) I just point about that if it was in main, then yeah, that will be my main process, but as this FindTask(NULL) only in patched CallHookPkt, then , together with check on only my binary to trace (via cmd_CommandName), we at this point kind of sure (i were in hope) that this is the process we had, and we not need any new "findtask" for , as we already can suspend it from &process->pr_Task.
Quote:
However, looking again at the code of callhookpkt_stacktrace_v1.c, this may be easier than it seems. Is this libauto as no libraries are opened? Also, where is IDebug filled in? I don't see any protos for it nor am aware of libauto able to open debug interface of Exec.
IDebug is an Exec's thing, and yeah i use libauto: i tested by standalone binary (without patching involved) and IDebug handles well by it and stack trace working for let's say FindTask("Workbench").. But not when i put my process to trace on : it simple hang binary i want to trace+stack-trace right after first CallHookPkt() call.
Maybe when we in patched function i should obtain IDebug again ?
if (hookstack != NULL)
{
IExec->FreeSysObject(ASOT_HOOK, hookstack);
}
}
But when i put the same exactly code to the main , and leave patching function just pure return to original CallHookPkt, then it works.
So just setting of the Hook inside the patched CallHookPkt cause crash, not the issues with task/process/etc. And it does not matter what my actual printStack function are: i even tried it to be just an empty one.
I.e. pure set of any hook inside the patched CallHookPkt() = crash. Probably that what Joerg mean when says "Exclude own hook from patched CallHookPkt to avoid endless loop and crash" ? But then, my task is explicitly "serial.device", so not the main one ..
Edited by kas1e on 2024/5/4 11:59:05 Edited by kas1e on 2024/5/4 12:01:49 Edited by kas1e on 2024/5/4 12:04:20 Edited by kas1e on 2024/5/4 12:09:29 Edited by kas1e on 2024/5/4 12:12:43
but this can also be dangerous, because you do not know if your patched is being called inside a forbid(), the permit() can break the forbid() at the wrong time. So you should first check if your inside a forbid, before you do a forbid, and a permit.
Also, if your dealing with another task, it can be unloaded from memory, before you which. So again you should not peek & poke in another tasks Task struct, unless you know you have exclusive asses to it, task struct does not have a locking mechanism, mutex/semaphore, so you most block multitasking.
If you are just comparing task pointers, and not looking inside it, you don’t need to worry about it much, but it can be a different task, then you expected, as memory is often reused in AmigaOS4, but it highly unlikely. More likely the memory will end up being used for something else.
IExec->FindTask(NULL);
does not search the list, and is therefor is safe. no forbid, permit needed. And if you are working on yourself, you expect nothing is unloaded.
Edited by LiveForIt on 2024/5/4 13:00:59 Edited by LiveForIt on 2024/5/4 14:06:22
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@LiveForIt This all just for tests (serial.device i mean). Problem currently is seems in the fact that i set hook from hooked CallHookPkt(), and i need exclude my hook from patched CallHookPkt somehow (but can't see how can i do so by ObtainDebugSymbol() )
You shouldn't allocate memory in a patched function as that will for example break a Forbid() or Disable() state. You can't use the IDebug functions in the patch either, maybe StackTrace() is no problem if you use IExec->DebugPrintF() instead of IDOS->Printf(), but for example ObtainDebugSymbol() which has to re-open the ELF file handle can't be used. Getting the symbols/module name and any output, except for DebugPrintF(), has to be done in your main() task, not in a task calling a patched function.
Instead of using task/CLI names I'd use the unique PID instead, if it's a DOS process and not an exec task. "serial.device"? If that's really serial.device (or a replacement) it's probably not a DOS process.
Wait, you say i can't allocate memory in the patched function, but i use before in patched function all those allocmems, char *buffers and co, with no problems ? Or by allocating memory, you mean exactly allocating memory for the hook ?
Anyway, i put allocating/deallocating of the hook for StackTrace in the main, but then, why SuspendTask() still suspend the main one, and not the one &process->pr_Task are (which by checks on cli_commandname is the one i need) ?
Strange that i can't just do that:
if(!stricmp(buffer,traced_binary))
{
if (&process->pr_Task != NULL)
{
if (hookstack != NULL)
{
IExec->SuspendTask(&process->pr_Task,0);
IExec->RestartTask(&process->pr_Task,0);
}
}
}
It just suspends task one time, and never do restart task. Even it if suspend my main one, why it didn't restart it after ? But then i am in the process with cli_commandname i need, so why it didn't suspend this one instead ? Or it is , just can't restart after ?
@kas1e Maybe I don't understand the problem in the first place but I think if you're in the hooked function then you're running within the task that called the function you've replaced so whatever you do will affect the caller. If you suspend the task then it will not be run any more so the next line that would resume it won't be reached and there's nothing else to resume it. If you can't walk the stack to find the callers from the hooked function then I think what you might need to do is implement getting a stack trace in your main program and create a message port to invoke this stack trace collecting function on the task passed in the message. Then from the hooked function send the process id to the main program and wait until it replies. This will suspend the task waiting for the reply until the main program can collect the stack trace then it can resume the caller by replying to the message. This is what @Hypex proposed above if I got that correctly.
@balaton Right, so it means that we can only suspend/obtainstack/remove from any other task/process (not exactly from main(), but anything else which is not caller's task).
I tried simple call StackTrace() without Suspend/Restart task from the main() of Workbench task (just for tests) : and it works. But when i tried to do the same StackTrace() without Suspend/Restart from patched CallHookPkt (from the same Workbench task) i then crash and burn right at calling StackTrace() :)
if (h != NULL)
{
/* Use the utility library function to invoke the Hook */
IUtility->CallHookPkt (h, NULL, NULL);
IExec->FreeSysObject(ASOT_HOOK, h);
}
exit(0);
}
Now, if i install a patched CallHookPkt, find my binary name of this test case as process, and printf a DebugPrintF there (and nothing else) , then for single CallHookPkt() from my test app, i do have 100 CallHookPkts runs in whole system.
Why not a single one ? Is it mean that one my call, involve 100 other ones in the deep of the system (DOS, Intuition, etc ?)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
