Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
56 user(s) are online (39 user(s) are browsing Forums)

Members: 0
Guests: 56

more...

Support us!

Headlines

 
  Register To Post  

« 1 2 (3) 4 5 6 »
Re: Tracing
Home away from home
Home away from home


See User information
@All
So that what i did for pure simple test:

I just internally (out of patched CallHookPkt() ) do:

struct Process *process_to_inspect = NULL;

Then, in the patched CallHookPkt i did that:

// patched functions
ULONG APICALL Patched_CallHookPkt(struct UtilityIFace *Selfstruct Hook *hookAPTR objectAPTR message) {


    
struct Process *process = (struct Process *)IExec->FindTask(NULL);

    if (
IS_PROCESS(process))
    {
        
struct CommandLineInterface *cli BADDR(process->pr_CLI);

        if(
cli)
        {            
            if(
cli->cli_Module)
            {
                static 
char buffer[128];
                
IDOS->CopyStringBSTRToC(cli->cli_CommandName,buffer,sizeof(buffer));
                
                if(!
stricmp(buffer,traced_binary)) 
                {
                        if (&
process->pr_Task != NULL)
                        {
                                if (
hookstack != NULL)
                                {    
                                    
process_to_inspect process;
                                }
                        }
                }

            }
        }
    } 

    return 
Original_CallHookPkt(Selfhookobjectmessage);


And in end, in the main i did that:

while(1)
    {
        
        
//if(IExec->Wait(SIGBREAKF_CTRL_C) & SIGBREAKF_CTRL_C) { 
        
if(IDOS->CheckSignal(SIGBREAKF_CTRL_C)) {
            break;
        }

        if (&
process_to_inspect->pr_Task != NULL)
        {
            
IExec->SuspendTask(&process_to_inspect->pr_Task,0);
            
uint32 result IDebug->StackTrace(&process_to_inspect->pr_Task,hookstack);
            
IExec->RestartTask(&process_to_inspect->pr_Task,0);
        }
    }


Now, when it simply Suspend/Restart : all works, no problems. Through 100% cpu loading and all crawl like a slideshow (opening of windowses, etc, 100% loading because of loop), but ok , it works.

Then once i keep this "StackTrace" : then it show me few lines of stack trace (5-10) and everything freezes (without crashlog). Sometime gives me more, sometime give less.

Stackframe decode function are:

case STACK_FRAME_DECODED: {

            
IExec->DebugPrintF("(%p) -> %p "frame->StackPointerframe->MemoryAddress);

            
struct DebugSymbol *symbol IDebug->ObtainDebugSymbol(frame->MemoryAddressNULL);

            if (
symbol) {

                if(
symbol->Type == DEBUG_SYMBOL_MODULE_STABS && symbol->SourceFileName)
                        
IExec->DebugPrintF("[%s: line %d]: %s\n"symbol->SourceFileNamesymbol->SourceLineNumbersymbol->SourceFunctionName);
                else if(
symbol->SourceFunctionName)
                        
IExec->DebugPrintF("%s\n"symbol->SourceFunctionName);
                else 
                        
IExec->DebugPrintF("[%s]\n"symbol->Name);

                
IDebug->ReleaseDebugSymbol(symbol);

            }

        }
        break;


How to do it all in proper way, so no crashes/freezes when obtain stacktrace ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Tracing
Just can't stay away
Just can't stay away


See User information
@kas1e
Quote:
Now, when it simply Suspend/Restart : all works, no problems. Through 100% cpu loading and all crawl like a slideshow (opening of windowses, etc, 100% loading because of loop), but ok , it works.
Setting process_to_inspect to NULL again after SuspendTask()/StackTrace()/RestartTask() seems to be missing.

Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@kas1e

if (&process_to_inspect->pr_Task != NULL)

this looks like a bug.

you get address of member pr_task in process_to_inspect and comparing to NULL.

you don't even know if process_to_inspect is NULL or not.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@Joerg
Quote:

Setting process_to_inspect to NULL again after SuspendTask()/StackTrace()/RestartTask() seems to be missing.


Damn, i set it first time, and then remove after test, so yeah, it's much better now. I add in patched CallHookPkt() also that:

if (hookstack != NULL)
                                {    
                                    
process_to_inspect process;
                                    
IExec->DebugPrintF("CallHookPkt call # %d\n"callhooks++);
                                }
                        }


And in main it's now:

if (&process_to_inspect->pr_Task != NULL)
        {
            
IExec->SuspendTask(&process_to_inspect->pr_Task,0);
            
uint32 result IDebug->StackTrace(&process_to_inspect->pr_Task,hookstack);
            
IExec->RestartTask(&process_to_inspect->pr_Task,0);
            
process_to_inspect NULL;
        }



And when i run my test case with simple CallHookPkt, that what i have in output:

CallHookPkt call # 0
CallHookPkt call # 1
CallHookPkt call # 2
CallHookPkt call # 3
CallHookPkt call # 4
CallHookPkt call # 5
CallHookPkt call # 6
CallHookPkt call # 7
CallHookPkt call # 8
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA430 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 9
CallHookPkt call # 10
CallHookPkt call # 11
CallHookPkt call # 12
CallHookPkt call # 13
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA430 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 14
CallHookPkt call # 15
CallHookPkt call # 16
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA430 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 17
CallHookPkt call # 18
CallHookPkt call # 19
CallHookPkt call # 20
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 21
CallHookPkt call # 22
CallHookPkt call # 23
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 24
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 25
(0x60D5B970) -> 0x01806528 [kernel]
(
0x60D5B980) -> 0x0183A73C [kernel]
(
0x60D5BA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BAD0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60D5BCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60D5BCF0) -> 0x0186E7E4 [kernel]
(
0x60D5BD20) -> 0x0186E838 [kernel]
(
0x60D5BD90) -> 0x01A650D0 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 26
CallHookPkt call # 27
(0x60D5BB30) -> 0x01806528 [kernel]
(
0x60D5BB40) -> 0x0183A73C [kernel]
(
0x60D5BC50) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC90) -> 0x019627A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x01962A44 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 28
CallHookPkt call # 29
CallHookPkt call # 30
CallHookPkt call # 31
(0x60D5BB30) -> 0x01806528 [kernel]
(
0x60D5BB40) -> 0x0183A73C [kernel]
(
0x60D5BC50) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC90) -> 0x019627A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x01962A44 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 32
CallHookPkt call # 33
CallHookPkt call # 34
(0x60D5BB30) -> 0x01806528 [kernel]
(
0x60D5BB40) -> 0x0183A73C [kernel]
(
0x60D5BC50) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC90) -> 0x019627A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x01962A44 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 35
(0x60D5BB30) -> 0x01806528 [kernel]
(
0x60D5BB40) -> 0x0183A73C [kernel]
(
0x60D5BC50) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC90) -> 0x019627A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x01962A44 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 36
CallHookPkt call # 37
CallHookPkt call # 38
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 39
CallHookPkt call # 40
CallHookPkt call # 41
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 42
CallHookPkt call # 43
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 44
CallHookPkt call # 45
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 46
CallHookPkt call # 47
CallHookPkt call # 48
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 49
CallHookPkt call # 50
CallHookPkt call # 51
CallHookPkt call # 52
CallHookPkt call # 53
CallHookPkt call # 54
CallHookPkt call # 55
CallHookPkt call # 56
CallHookPkt call # 57
CallHookPkt call # 58
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 59
CallHookPkt call # 60
CallHookPkt call # 61
CallHookPkt call # 62
CallHookPkt call # 63
CallHookPkt call # 64
CallHookPkt call # 65
CallHookPkt call # 66
CallHookPkt call # 67
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 68
CallHookPkt call # 69
CallHookPkt call # 70
CallHookPkt call # 71
CallHookPkt call # 72
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 73
CallHookPkt call # 74
CallHookPkt call # 75
CallHookPkt call # 76
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 77
CallHookPkt call # 78
CallHookPkt call # 79
CallHookPkt call # 80
CallHookPkt call # 81
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 82
(0x60D5BAD0) -> 0x01806528 [kernel]
(
0x60D5BAE0) -> 0x0183A73C [kernel]
(
0x60D5BBF0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC30) -> 0x019625A4 [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 83
(0x60D5BAA0) -> 0x01806528 [kernel]
(
0x60D5BAB0) -> 0x0183A73C [kernel]
(
0x60D5BBC0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BC00) -> 0x018439B8 [kernel]
(
0x60D5BC10) -> 0x01958034 [dos.library.kmod]
(
0x60D5BC30) -> 0x019623EC [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 84
(0x60D5BA00) -> 0x01806528 [kernel]
(
0x60D5BA10) -> 0x0183A73C [kernel]
(
0x60D5BB20) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BB60) -> 0x01843C94 [kernel]
(
0x60D5BBA0) -> 0x01957F74 [dos.library.kmod]
(
0x60D5BBC0) -> 0x7FFCB988 Patched_CallHookPkt
(0x60D5BC00) -> 0x018439B8 [kernel]
(
0x60D5BC10) -> 0x01958034 [dos.library.kmod]
(
0x60D5BC30) -> 0x019623EC [dos.library.kmod]
(
0x60D5BCE0) -> 0x019628D8 [dos.library.kmod]
(
0x60D5BD20) -> 0x01A63C50 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65150 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 85
(0x60D5BBB0) -> 0x01806528 [kernel]
(
0x60D5BBC0) -> 0x0183A73C [kernel]
(
0x60D5BCD0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BD10) -> 0x7FACE5E8 main
(0x60D5BD40) -> 0x01A64CD4 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65A00 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 86
(0x60D5BB70) -> 0x01806528 [kernel]
(
0x60D5BB80) -> 0x0183A73C [kernel]
(
0x60D5BC90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BCD0) -> 0x01843C94 [kernel]
(
0x60D5BD10) -> 0x7FACE610 main
(0x60D5BD40) -> 0x01A64CD4 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A65A00 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 87
(0x60D5BBC0) -> 0x01806528 [kernel]
(
0x60D5BBD0) -> 0x0183A73C [kernel]
(
0x60D5BCE0) -> 0x7FFCB968 Patched_CallHookPkt
(0x60D5BD20) -> 0x01843C08 [kernel]
(
0x60D5BD60) -> 0x01A62F80 [newlib.library.kmod]
(
0x60D5BD90) -> 0x01A653B4 [newlib.library.kmod]
(
0x60D5BF40) -> 0x01A65F24 [newlib.library.kmod]
(
0x60D5BF70) -> 0x7FACE294 _start
(0x60D5BFC0) -> 0x0185F2B4 [kernel]
(
0x60D5BFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 88
(0x60E0C970) -> 0x01806528 [kernel]
(
0x60E0C980) -> 0x0183A73C [kernel]
(
0x60E0CA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CAD0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CCF0) -> 0x0186E7E4 [kernel]
(
0x60E0CD20) -> 0x0186E838 [kernel]
(
0x60E0CD90) -> 0x01C04774 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 89
(0x60E0C970) -> 0x01806528 [kernel]
(
0x60E0C980) -> 0x0183A73C [kernel]
(
0x60E0CA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CAD0) -> 0x7FFF9CE8 [LIBS:locale.library]
(
0x60E0CCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CCF0) -> 0x0186E7E4 [kernel]
(
0x60E0CD20) -> 0x0186E838 [kernel]
(
0x60E0CD90) -> 0x01C04774 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 90
(0x60E0C970) -> 0x01806528 [kernel]
(
0x60E0C980) -> 0x0183A73C [kernel]
(
0x60E0CA90) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CAD0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CCB0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CCF0) -> 0x0186E7E4 [kernel]
(
0x60E0CD20) -> 0x0186E838 [kernel]
(
0x60E0CD90) -> 0x01C047C8 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 91
CallHookPkt call # 92
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDC84 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 93
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDC84 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 94
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDC84 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 95
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDC84 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 96
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDC84 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 97
CallHookPkt call # 98
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFF9CE8 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDC84 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 99
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDA90 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 100
(0x60E0C8E0) -> 0x01806528 [kernel]
(
0x60E0C8F0) -> 0x0183A73C [kernel]
(
0x60E0CA00) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0CA40) -> 0x7FFF9CE8 [LIBS:locale.library]
(
0x60E0CC20) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0CC60) -> 0x0186E7E4 [kernel]
(
0x60E0CC90) -> 0x0186E838 [kernel]
(
0x60E0CD00) -> 0x01BFDA90 [shell.kmod]
(
0x60E0CD90) -> 0x01C047FC [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 101
CallHookPkt call # 102
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 103
CallHookPkt call # 104
CallHookPkt call # 105
CallHookPkt call # 106
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 107
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 108
CallHookPkt call # 109
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 110
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 111
CallHookPkt call # 112
CallHookPkt call # 113
CallHookPkt call # 114
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 115
CallHookPkt call # 116
CallHookPkt call # 117
CallHookPkt call # 118
CallHookPkt call # 119
CallHookPkt call # 120
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 121
CallHookPkt call # 122
CallHookPkt call # 123
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 124
CallHookPkt call # 125
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 126
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 127
CallHookPkt call # 128
CallHookPkt call # 129
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA430 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 130
CallHookPkt call # 131
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 132
CallHookPkt call # 133
CallHookPkt call # 134
CallHookPkt call # 135
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA4F0 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 136
CallHookPkt call # 137
CallHookPkt call # 138
CallHookPkt call # 139
CallHookPkt call # 140
CallHookPkt call # 141
CallHookPkt call # 142
CallHookPkt call # 143
CallHookPkt call # 144
CallHookPkt call # 145
CallHookPkt call # 146
(0x60E0C660) -> 0x01806528 [kernel]
(
0x60E0C670) -> 0x0183A73C [kernel]
(
0x60E0C780) -> 0x7FFCB968 Patched_CallHookPkt
(0x60E0C7C0) -> 0x7FFFA430 [LIBS:locale.library]
(
0x60E0C9A0) -> 0x7FFFBE70 [LIBS:locale.library]
(
0x60E0C9E0) -> 0x0186E7E4 [kernel]
(
0x60E0CA10) -> 0x0186E838 [kernel]
(
0x60E0CA80) -> 0x01985B50 [elf.library.kmod]
(
0x60E0CBB0) -> 0x0199245C [elf.library.kmod]
(
0x60E0CC00) -> 0x019924D0 [elf.library.kmod]
(
0x60E0CC70) -> 0x01981EDC [elf.library.kmod]
(
0x60E0CCD0) -> 0x01982274 [elf.library.kmod]
(
0x60E0CD40) -> 0x0196AB14 [dos.library.kmod]
(
0x60E0CD90) -> 0x01C05184 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]
CallHookPkt call # 147
CallHookPkt call # 148
CallHookPkt call # 149
CallHookPkt call # 150
CallHookPkt call # 151
(0x60E0CC90) -> 0x01806528 [kernel]
(
0x60E0CD00) -> 0x0193D430 [dos.library.kmod]
(
0x60E0CD20) -> 0x018C7E10 [SmartFilesystem]
(
0x60E0CD50) -> 0x019653D0 [dos.library.kmod]
(
0x60E0CD70) -> 0x01C02D48 [shell.kmod]
(
0x60E0CD90) -> 0x01C04E80 [shell.kmod]
(
0x60E0CF50) -> 0x01C05D8C [shell.kmod]
(
0x60E0CFC0) -> 0x0185F2B4 [kernel]
(
0x60E0CFD0) -> 0x0185F32C [kernel]


Now.. What curious me is: Why we have some CallHookPKt calls from patched function without actual stack trace, but only for some of them

And now it is clear which libs/components are involved when one call CallHookPkt (or maybe, its not CallHookPkt cause it, but runnning of any binary ? that need to test)

Is it possible to transfer addresses to the names of functions so stack trace output will be more readable ? Or it's only possible if library build with -gstabs ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Tracing
Just can't stay away
Just can't stay away


See User information
@LiveForIt
Quote:
if (&process_to_inspect->pr_Task != NULL)

this looks like a bug.
That's just an over-complicated way of using if (NULL != process_to_inspect)

(Not 100% sure about the way that's interpreted by the compiler, but at least "&(process_to_inspect->pr_Task)" would be identical to just "process_to_inspect".)

Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@kas1e

Is it possible to transfer addresses to the names of functions so stack trace output will be more readable ? Or it's only possible if library build with -gstabs ?

Well... you should find more info then this, you only showing the module. not everything is stripped.

Even if it is stripped.

addresses can be looked up in the interface, you know the layout of interfaces as documented in inline4 header files.

by closest match, or by comparing the address between interfaces.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: Tracing
Quite a regular
Quite a regular


See User information
@kas1e
Constantly polling process_to_inspect global variable in an infinite loop is not only very inefficient as you've found but also not safe in a multitasking environment, because another process could call your hooked function while it's still collecting a stack trace and that would overwrite process_to_inspect during the stack trace function is running. You really should send the process id via a message or some other IPC mechanism and make the stack tracing function reentrant (i.e. not using any globals) so it won't break if invoked by different processes at the same time. Invoking this with a message would both avoid 100% CPU usage from busy waiting and avoid needing Suspend/Restart as the traced process would wait for the message.

I don't know how to get more detailed info but you probably would need to at least run debug kernel to get info on kernel functions and may need debug versions of libraries too which may not be available.

Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@joerg
CallHook
Quote:

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.


It seems that in end we do have also CallHook() separated from CallHookPkt() and not from amiga.lib, but from utility.library. See from interfaces/utility.h:

ULONG APICALL (*CallHookPkt)(struct UtilityIFace *Selfstruct Hook hookAPTR objectAPTR message);
    
ULONG APICALL (*CallHook)(struct UtilityIFace *Selfstruct Hook hookAPTR object, ...);


Also, from utility.library autodoc:

Quote:

The second form, CallHook, allows the message packet to be built on the stack.


So, linear varargs :( (hate that varargs mess).


To patch this i probably should somehow correctly return to original with calling all those "va_list/va_start/etc/etc" ? I mean:

ULONG APICALL Patched_CallHook(struct UtilityIFace *Selfstruct Hook *hookAPTR object, ...) {

IExec->DebugPrintF("pure CallHook %d\n"purecallhookcounts++);

va_list argp;
va_start (argpobject);
va_end (argp);
return 
Original_CallHook(Self,hook,object,argp);


}


Like that ? Shouldn't i somehow detect the type and amount of the arguments coming to , and then return them only ? I mean can't do "return Original_CallHook(Self, hook, object, ...)" , but i can't assume type and amount of .. how to deal with ?

Always hate this varargs stuff, and very sure there is no more involved with CallHookPkt, and like CallHookPkt() is one and single one :)

Anyway, that all mean, that CallHookPkt() and CallHook() both from utility.library, are separate functions, and both need to be patched independently, as CallHookPkt to not call CallHook() for sure (i asked one os4 dev about, he checked sources, and they indeed separate functions).

Looks like before, in ancient times, it was in libamiga.a, then it also was in clib2 too (but only for 68k), and when it seems start to be first ppc versions of uitilty.library, they made CallHook() inside of it too (through not sure there, but looks like this, as why to have 2 different CallHook() one in amiga.lib and one in utility.library .. )

At least that explain why we have no so many CallHook calls as you may expect maybe ?

stacktrace

Btw, checking Alfkil's SpotLess source code i found this:

https://github.com/alfkil/Spotless/blo ... mpleDebug/Stacktracer.cpp

See, there he point that getting stack trace by IDebug, is "unsafe" way (dunno why), instead, he get ElfHandle and then by IElf->SymbolQuery get the same info one get from IDebug->StackTrace.


@balaton

Yeah, busylooping take 100% cpu loading, which i kind of fix by adding IDOS->Delay(1) in , but that of course ugly crap :)

Through i still don't understand one moment : why when i simply run my CallHookPkt() test case, i have about 150 calls of CallHookPkt() from patched function, but only 12 StackTraces.. I was expected to have the same amount : for each call of patched CallHookPkt - one StackTrace.

Quote:

I don't know how to get more detailed info but you probably would need to at least run debug kernel to get info on kernel functions and may need debug versions of libraries too which may not be available.

Debug kernel sadly didn't build with -gstabs, it only "debug" in meaning that it have more IExec->DebugPrintF to throw on serial when require it, but it didn't build with -gstabs.

But from another side, LiveForIt have a point : can't I just by offsets in the memory known the name of function ? DebugSymbol structure (from exec/debug.h) do have this field : "Offset into the module", so I can make some internal resolver probably ? Like checking , if modulename = kernel, then take offsets, compare it with the list of functions from include files, and out the correct one in human look ?


@all
Current version, which kind of works, but with no IPC:

https://kas1e.mikendezign.com/aos4/tra ... llhookpkt_stacktrace_v2.c

Sometime this version simple hang forever and stop output on serial : system continue to work, but just test binary never exit and i can't interrupt the traces by ctrl+c. Sometimes it works. Often it works after reboot, but second run acts like this.

Anyway, how to make proper IPC there ? I mean, I'm never doing so, are there any templates to follow ? Like:

patced_function()
{

 
get_proc +  check_name 
 
if (my_name) {
    
send message ?
 }

}

main()
{

while(
1) {
   
wait for message

}

}


thanks!


Edited by kas1e on 2024/5/6 3:06:53
Edited by kas1e on 2024/5/6 3:19:32
Edited by kas1e on 2024/5/6 3:31:51
Edited by kas1e on 2024/5/6 4:01:24
Edited by kas1e on 2024/5/6 4:29:04
Edited by kas1e on 2024/5/6 4:29:53
Edited by kas1e on 2024/5/6 4:37:14
Edited by kas1e on 2024/5/6 4:54:32
Edited by kas1e on 2024/5/6 5:54:06
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Tracing
Not too shy to talk
Not too shy to talk


See User information
@kas1e

Quote:
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.


Okay, I didn't know libauto would pick it up. So it must open all interfaces of Exec? Doesn't look efficient opening things you don't always need.

Quote:
Maybe when we in patched function i should obtain IDebug again ?


Well that would incur more overhead and would likely be unnecessary. Unless it was not thread safe. I think pulling it from your global IDebug after your main code has opened it is good enough.

Quote:
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 ..


It should be fine to allocate a hook. I didn't see it before but the "IDebug->StackTrace(&process->pr_Task,hook)" would have gone into a circular loop I imagine when it ended up calling the hook and then called Patched_CallHookPkt again.

Quote:
It seems that in end we do have also CallHook() separated from CallHookPkt() and not from amiga.lib, but from utility.library. See from interfaces/utility.h:


Yes another function you may need to patch.

Quote:
Always hate this varargs stuff, and very sure there is no more involved with CallHookPkt, and like CallHookPkt() is one and single one :)


Never knew why there was the "Tags" functions and then "Attr" or "TagList" functions. Some had their own entry. All of them in 68K land would have been an address to a tag list at the ABI level. But at the API level they over complicated it. I didn't see why two functions were needed that would be doing exactly the same thing.

For PPC where it doesn't have a stack and can't just stack data so the epilogue must create it with a stack frame I can see it being needed. But the va stuff messes up all code I can see. Regardless of CPU.

Quote:
See, there he point that getting stack trace by IDebug, is "unsafe" way (dunno why), instead, he get ElfHandle and then by IElf->SymbolQuery get the same info one get from IDebug->StackTrace.


That could be because you may pick up an illegal address off the stack trace. You may need to verify it with TypeOfMem(). That's what I started doing with unknown addresses.

Quote:
But from another side, LiveForIt have a point : can't I just by offsets in the memory known the name of function ? DebugSymbol structure (from exec/debug.h) do have this field : "Offset into the module", so I can make some internal resolver probably ? Like checking , if modulename = kernel, then take offsets, compare it with the list of functions from include files, and out the correct one in human look ?


I've had this idea for years to do something like that. Like a program that can read a stack track and replace all vague offsets with real functions. An advanced addr2line so to speak. Exec and others doesn't change much. But I think an automated way of reading interfaces would be needed that builds up a list itself. Which can then be used as a reference in a program to do a reverse name lookup on a stack trace.

Quote:
Anyway, how to make proper IPC there ? I mean, I'm never doing so, are there any templates to follow ? Like:


A few ways would be:
* Just use one global structure from main program. And assign a signal in main program. Protect it with a semaphore or mutex so every time you want to use it you lock it, fill it in and signal master task. Master task will process then in patch wait for master to signal back when done.

* Just use a local structure in patch. Send it to your master task as a message and wait for it to signal back. Like above but it will be thread safe from race conditions.

* Allocate a block of memory for structure on each call. Then use the above method.

The first is like you are doing but you avoid the busy loops by using signals. Of course you would be locking the data first.

To avoid more code locking it the second one may be easier.

The third has some slight overhead but works like the second.

Go to top
Re: Tracing
Not too shy to talk
Not too shy to talk


See User information
@LiveForItQuote:
if (&process_to_inspect->pr_Task != NULL)


Although it's rather verbose this is not so much a trick but good technique. The "&process_to_inspect->pr_Task" looks redundant but this in fact avoids a cast. Being that every Process is a Task but not every Task is a Process, means you can't just throw one generic pointer around, so sometimes you need Task and other times Process. This is a good way to use one Process pointer for both.

I need to remember this way because looking at my code I've got a Task that I'm currently doing a "(struct Process *) on and it just looks messy. BCPL pointers are bad enough.

Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@Hypex
Quote:

I've had this idea for years to do something like that. Like a program that can read a stack track and replace all vague offsets with real functions. An advanced addr2line so to speak. Exec and others doesn't change much. But I think an automated way of reading interfaces would be needed that builds up a list itself. Which can then be used as a reference in a program to do a reverse name lookup on a stack trace.


When i simple printf that:

IExec->DebugPrintF("ModuleName: [%s] FunctionOffset: %x\n"symbol->Namesymbol->Offset);


Then in return i had for one of stacktraces this:

ModuleName: [kernelOffset6544
ModuleName
: [kernelOffset3C338
ModuleName
: [dos.library.kmodOffsetE71C
ModuleName
: [dos.library.kmodOffset2B3B8
ModuleName
: [SmartFilesystemOffset630
ModuleName
: [dos.library.kmodOffset2D448
ModuleName
: [dos.library.kmodOffset3E228
ModuleName
: [dos.library.kmodOffset3E760
ModuleName
: [dos.library.kmodOffset12018
ModuleName
: [shell.kmodOffset395C
ModuleName
: [shell.kmodOffset7708
ModuleName
: [shell.kmodOffset91CC
ModuleName
: [kernelOffset5F2B4
ModuleName
: [kernelOffset5F32C


But those offsets didn't looks sane enough for me .. I were expected for something like numbers starting from 0 and more pointing on the function's order in the list of the functions as described in the interface. Or it not that "offset" ?


And ok, i know the offsets of the functions for each library, but what about "kernel" module for example ? We can't know what calls of what sub-library it did (exec/utility/etc) so we can't just by knowing name "kernel" and offset, to know what function is it. That probably can works with libraries only, but we need normal offset, because i currently can't get what this offset mean for example:

(0x61C57490) -> 0x01C528D0 ModuleName: [graphics.library.kmodOffset0x00036790
(0x61C57570) -> 0x01C401BC ModuleName: [graphics.library.kmodOffset0x0002407C


I didn't get what this "offset" mean, in the headers it called "Offset into the module", but that not looks like offsets in jump table ?

DebugSymbold structure also have this:

uint32 SegmentNumber;            // DOS segment number
    
uint32 SegmentOffset;            // DOS segment offset


But also dunno what this offset are..

So... how can we get offset of the called function of library in the jump table ?


Edited by kas1e on 2024/5/6 13:53:17
Edited by kas1e on 2024/5/6 14:31:25
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Tracing
Not too shy to talk
Not too shy to talk


See User information
@kas1e

Quote:
But those offsets didn't looks sane enough for me .. I were expected for something like numbers starting from 0 and more pointing on the function's order in the list of the functions as described in the interface. Or it not that "offset" ?


I can see two offsets at play here. The interface jump table function offsets. And the binary code offsets.

Quote:
And ok, i know the offsets of the functions for each library, but what about "kernel" module for example ? We can't know what calls of what sub-library it did (exec/utility/etc) so we can't just by knowing name "kernel" and offset, to know what function is it. That probably can works with libraries only, but we need normal offset, because i currently can't get what this offset mean for example:


The base call offset from the interface jump should be on the bottom of the stack trace at the point a program calls an OS function. It's true we can't know what other calls it makes. And, the OS won't necessarily call itself from the external function interface, but will make a direct function call.

But usually what we see with module kernel+0x is the actual code offset into the binary. Same as with -gstabs code you see the name with function and offset. So offset would be offset from function code prologue.

Quote:
I didn't get what this "offset" mean, in the headers it called "Offset into the module", but that not looks like offsets in jump table ?


No, because it's gone beyond that. Depending how it implements it the function jump should be in stack but it may be optimised away. Creating a stack frame on every jump call would be inefficient so the API call logic may do the minimum to call the function.

Not sure if GCC or what ever compiler can be told to build stack frame on API call. Like the opposite of -fomit-frame-pointer.

Quote:
So... how can we get offset of the called function of library in the jump table ?


With only an offset this is where it gets complicated. I'd say we'd need to walk the list of interface functions and build up a list of offsets from base code where ELF is loaded. They may not be in order either so it cannot be expected for functions to appear in sequential order unless they really are. Which is handy for calculating a size window for each function code block, but the table off offsets to address can be ordered later. However, the address from each jump might be just enough to do it. With a bit of math, the nearest function to that offset can be located.

I think I've made this look complicated. This is probably easier than my manual thinking of doing it by hand. There's likely other ways of doing this in the outside world. I mean it's all based on ELF anyway which is common. The answer may be on Stack overflow.

Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@Hypex
In other words, even if we know that we can do something because of jump table and interfaces, we still dont know for now how to detect what function of the stacktraced library (at least library) were called :(

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@kas1e

Some libraries you can find the initCode in the Residents list.

only problem is that initCode does not need to be in the start of library, but it’s in the code section.

Perhaps if you look at _start and determine where its in the ELF header, you can work your way backwards, to actual first code.


Edited by LiveForIt on 2024/5/6 16:54:01
Edited by LiveForIt on 2024/5/6 16:57:07
Edited by LiveForIt on 2024/5/6 16:57:59
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@Hypex

I don’t know why you want your code to have more likely bugs.

&ptr->member;

is the same as

(struct *)((char *) ptr + offsetof(struct,member))

now image you pointer is NULL, first is offset 0, 2en is offset 4, now image if member is 2en.

this means you have something like this:

if ((ptr+4) == NULL)

And this will never be NULL

The only thing you need to do, to screw up your code, is add a new member at the beginning of your struct, and your code breaks.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: Tracing
Just can't stay away
Just can't stay away


See User information
@Hypex
Quote:
And, the OS won't necessarily call itself from the external function interface, but will make a direct function call.
At least for 99% of the OS4 code doesn't use direct function calls but always goes through the interface of the library.

Quote:
Not sure if GCC or what ever compiler can be told to build stack frame on API call.
On OS4 VARARGS68K and va_(get|start)linearva does that. It was required for compatibility to emulated m68k code passing the arguments on the stack and it's used for example for all of the varargs TagItem functions.
Something like
int32 FooBar(uint32 arg1uint32 arg2struct TagItem *tags[]);

VARARGS68K int32 FooBarTags(uint32 arg1uint32 arg2, ...)
{
   
int32 result;
   
va_list args;
   
va_startlinear(argsarg2);
   
result FooBar(arg1arg2va_getlinearva(argsstruct TagItem **));
   
va_end(args);
   return 
result;
}

Go to top
Re: Tracing
Just can't stay away
Just can't stay away


See User information
@LiveForIt
In general your argument is valid, but for the &process->pr_Task case the offsetof(struct Process, pr_Task) is 0 and therefore can't cause problems.

Go to top
Re: Tracing
Quite a regular
Quite a regular


See User information
@kas1e
Quote:
Yeah, busylooping take 100% cpu loading, which i kind of fix by adding IDOS->Delay(1) in , but that of course ugly crap :)

Through i still don't understand one moment : why when i simply run my CallHookPkt() test case, i have about 150 calls of CallHookPkt() from patched function, but only 12 StackTraces.. I was expected to have the same amount : for each call of patched CallHookPkt - one StackTrace.


First call to hook sets process_to_inspect. Then another process calls CallHookPkt and your hook function overwrites process_to_inspect. This happens a few times until your main process gets a chance to run or finishes the delay and notices process_to_inspect is != NULL and suspends the last process that overwrote the global variable. Then goes on to collect the stack trace, if unlucky, there was already another call from another process so process_to_inspect now points to some other process not which was suspended. Then collects trace of that process and restarts some random process at the end, depending if there was more calls that replaced process_to_inspect while the stack trace was running. This won't work this way. You need to make the trace collection function not depend on any globals and pass the process id to trace via a message or some other way that's not overwritten by another call to your hook function. Since the hook function can also be invoked by several tasks simultaneously (it can be preempted while running and another process could call it again) it also cannot use globals. You could add locking to avoid these problems and only allow one instance of the hook and stack collection to run at a time but that would stall every other caller until stack collection is finished and create a bottleneck in your tracer. It's better to make the trace collection reentrant so it can be called multiple time on different processes without breaking and connect it to a message port so it can be invoked thorugh a message. Then hook function only needs to send the message and wait for reply which is again something that's independent of all other calls, it can constuct the message in a local stack variable so then multiple tasks can invoke this simultaneously and the separate calls can commence without blocking each other.

Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@Balaton
Thanks for detailed answer ! But on small nitpiking :

Quote:

First call to hook sets process_to_inspect. Then another process calls CallHookPkt and your hook function overwrites process_to_inspect. This happens a few times until your main process gets a chance to run or finishes the delay and notices process_to_inspect is != NULL and suspends the last process that overwrote the global variable.


But my code of Patched CallHookPkt, is checking on the process to be exactly only from my binary, all the other processes/tasks and whatever skips and returns to original CallHookPkt, without settings process_to_inspect to anything, and it continues to be NULL. It's only set to not NULL, if it only processes, and if it only processes with cli_command name of my choose (so, sets only for CallHookPkts coming from process from my binary).


Maybe issue not with "another process overwrite process_to_inspect", but the same process (my traced binary) overwrite it and main one just not have time to handle them all. I.e. my binary invoke 150 CallHookPkt's calls, CallHookPkt handle it well, just the main task with it's global have no time to handle them all as expected, but they all still from the same process (my binary).

Quote:

You need to make the trace collection function not depend on any globals and pass the process id to trace via a message


Yeah, that the way i will go now.

Quote:

You could add locking to avoid these problems and only allow one instance of the hook and stack collection to run at a time but that would stall every other caller until stack collection is finished and create a bottleneck in your tracer.


At least i can try to made this one firstly, to see how it works with bottleneck, and then make the trace collection reentrant.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Tracing
Home away from home
Home away from home


See User information
@kas1e

perhaps you should add

SetSignal( main_task, wakeup_signal );

in your trap, to notify you have something to do, instead of busy looping.

Then use wait in your main() function, as you should.

ActiveSignals = wait(1L << wakeup_singal | CTRLC );

Also you should check if your in forbid or not, as this can give you the option to freeze the trapped task, for a better stack trace. just restart it in main()

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top

  Register To Post
« 1 2 (3) 4 5 6 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project