Who's Online |
72 user(s) are online ( 42 user(s) are browsing Forums)
Members: 0
Guests: 72
more...
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:29
#41
|
Home away from home 
|
@joerg Quote:
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).
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:27
#42
|
Just can't stay away 
|
@kas1e Quote: Clib2 indeed have amiga_callhook.c and amiga_callhooka.c: But both with
#if (defined(__GNUC__) && !defined(__PPC__))
or
#ifndef __PPC__
The PPC clib2 libamga.a amiga_callhooka.o can only be an useless, empty object.
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:11
#43
|
Home away from home
|
@joerg Quote:
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: https://github.com/adtools/clib2/blob/ ... rary/amiga_callhook.c#L49https://github.com/adtools/clib2/blob/ ... ary/amiga_callhooka.c#L61But 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).
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:01
#44
|
Just can't stay away
|
@kas1e Quote: 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.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: Yesterday 4:55
#45
|
Just popping in 
|
@MamePPCA1
It's hard to answer without knowing what's stopping the partition showing up. But if they don't show up in DirOpus they won't appear in the other backup programs as well. However, with DirOpus you also need to add your partitions to the list on the left unless you right click on the "S" button near the centre, to see your partitions.
So when you booted the pen drive did they show up? Does your Workbench show up? If you can see that then you can at least back it up.
Also, be careful of SFSSalv. It's rather old now and SFS has been updated since. Since you have an X5000 you should also have Enhancer included. This has an updated SFS as well as PartitionWizard. This can check your partitions for errors and also do a backup. The Salvage option can back up to another drive.
You have SFS\2 volume as well. I've had one in the past but it broke. I had to salvage the data. As mentioned SFS\2 lacks recovery tools. I've avoided it since. I may have been able to backup by copying off Workbench before the filessystem totally destroyed itself.
It's recommend to use NGFS now as it's a modern filesystem with 64 bit support and can replace both SFS\2 and JXFS with a supported filesystem that has recovery tools. But, the catch is, it's only released for X5000. It's constantly updated to fix bugs. However, there's no easy way to update it, as you are expected to track down the developers email address and ask for it.
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 4:25
#46
|
Home away from home
|
@joerg Is for every run of CallHookPkt i should install a hook, grab stack trace, and remove hook ? For now i have that: https://kas1e.mikendezign.com/aos4/tra ... llhookpkt_stacktrace_v1.cBut 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
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
|
Quite a regular 
|
@Hypex .Quote: Hypex wrote:@MamePPCA1
Personally, I've tried these backup programs before, but end up giving up. Not sure what it was but they can get stuck if a file system has errors. I tend to go back to Workbench even though that has flaws.
Both are old designs and a strange mix. One is 68K so using old DOS functions but simple enough. The other is updated for OS4 but still using an old interface and is slightly confusing to use.
I'd use the older BackUp given the choice. Just needs source and destination. But, you could also just use a tool like DirOpus. That may be the easier option. All you say is good but,how can I use an app like Directory Opus 4 if the partitions doesn't appear? I really need a solution to this mess as soon as possible.
|
|
Amiga 500 1MB Chip RAM with ACA 500+ACA1232,CD32,Amiga 1300 030/50 Mhz,32MB (now on my hands at least)and Amiga One G3 XE PPC 800 Mhz,ATI Radeon 9250 128 MB,256 MB RAM,Seagate 200 GB HD,2 working DVD drives,X-Arcade double for MAME,Sil0680,4 USB ports,LG
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
|
Quite a regular
|
@joerg
OK I take note,but I think I've hearded it before.
|
|
Amiga 500 1MB Chip RAM with ACA 500+ACA1232,CD32,Amiga 1300 030/50 Mhz,32MB (now on my hands at least)and Amiga One G3 XE PPC 800 Mhz,ATI Radeon 9250 128 MB,256 MB RAM,Seagate 200 GB HD,2 working DVD drives,X-Arcade double for MAME,Sil0680,4 USB ports,LG
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@joerg But then, if involved components didn't build with gstabs, i will be unable to see what happems even with stacktrace, right ? For example i cookie up this based on exec doc and spotless debugger:
#include <proto/exec.h>
#include <proto/dos.h>
#include <exec/types.h>
#include <exec/interrupts.h>
#include <exec/tasks.h>
#include <dos/dos.h>
#include <stdio.h>
int32 printStack(struct Hook *hook, struct Task *task, struct StackFrameMsg *frame)
{
switch (frame->State)
{
case STACK_FRAME_DECODED: {
IDOS->Printf("(%p) -> %p ", frame->StackPointer, frame->MemoryAddress);
struct DebugSymbol *symbol = IDebug->ObtainDebugSymbol(frame->MemoryAddress, NULL);
if (symbol) {
if(symbol->Type == DEBUG_SYMBOL_MODULE_STABS && symbol->SourceFileName)
IDOS->Printf("[%s: line %d]: %s", symbol->SourceFileName, symbol->SourceLineNumber, symbol->SourceFunctionName);
else if(symbol->SourceFunctionName)
IDOS->Printf("%s", symbol->SourceFunctionName);
else
IDOS->Printf("[%s]\n", symbol->Name);
IDebug->ReleaseDebugSymbol(symbol);
}
}
break;
case STACK_FRAME_INVALID_BACKCHAIN_PTR:
IDOS->Printf("(%p) invalid backchain pointer\n",frame->StackPointer);
break;
case STACK_FRAME_TRASHED_MEMORY_LOOP:
IDOS->Printf("(%p) trashed memory loop\n", frame->StackPointer);
break;
case STACK_FRAME_BACKCHAIN_PTR_LOOP:
IDOS->Printf("(%p) backchain pointer loop\n",frame->StackPointer);
break;
default:
IDOS->Printf("Unknown state=%lu\n", frame->State);
}
return 0; // Continue tracing.
}
int main()
{
struct Task *task = IExec->FindTask("Workbench");
if (task != NULL)
{
struct Hook *hook = IExec->AllocSysObjectTags(ASOT_HOOK, ASOHOOK_Entry, printStack, TAG_END);
if (hook != NULL)
{
IExec->SuspendTask(task, 0);
uint32 result = IDebug->StackTrace(task, hook);
IExec->RestartTask(task, 0);
IExec->FreeSysObject(ASOT_HOOK, hook);
}
}
}
And the output are:
12/0.Work:hooks> stacktrace
(0x64da8e80) -> 0x01806544 [kernel]
(0x64da8eb0) -> 0x0183c338 [kernel]
(0x64da8f10) -> 0x7ff0edd8 [LIBS:workbench.library]
(0x64da8fc0) -> 0x0185f2b4 [kernel]
(0x64da8fd0) -> 0x0185f32c [kernel]
So for "workbench" task we had this stack trace. At lest we can see the components involved ..
Edited by kas1e on 2024/5/4 4:26:04
|
|
|
|
|
|
Re: Snes9x NG version 1.62.3 release 4 Software/Opengl/EGL_Wrapper renderers
|
|
Quite a regular
|
@HunoPPC Quote:
Thank you for your feedback but I personally tested this new version on native machines (SAM440, software and opengl rendering actually goes through SDL1 but I don't see the connection).
The Qemu/Pegasos2 machine currently has problems with old SDL1 libraries and it leads to unsightly artifacts and distortions. The AmigaOneXe/Sam460 machine does not have these problems and we do not yet know exactly what the problem is, as the Pegasos2/AmigaOneXe machine is based on the same code. At the moment it is suspected that it could be something in the AmigaOs4.1 kernel that only occurs with the Pegasos2 version of AmigaOs4.1 in combination with the SiliconMotion 502 graphics card. As far as we know it is due to the 16-bit bitmaps of SDL1 SDL2 from version 2.26.5 uses 32-bit bitmaps in all applications and this also works very well under Qemu/Pegasos2. https://github.com/AmigaPorts/SDL/rele ... /v2.26.5-release-amigaos4If possible could you provide the software renderer via SDL2 so that it works on all systems? For example: MilkyTracker/BreakHack/LiteXL and new ports that use SDL2 libraries for software rendering work without problems. On real hardware it doesn't matter if the software renderer is available via SDL1 or SDL2 as 3D acceleration is mainly preferred here.
Edited by Maijestro on 2024/5/3 19:23:58
|
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Quote: Of course probably the best way will be to use GDB or db101/spotless, and instruction by instruction find out how the way from user application till final CallHookPkt() passed , but maybe it possible to trace without debugger and in more automatic way ? You have to implement a stack backtrace in your IUtility->CallHookPkt() patch using IDebug->StackTrace() (problem: It's using a hook as well and you have to exclude this hook in your patch, otherwise you'll get an endless loop and crashes), IDebug->ObtainDebugSymbol(), etc., just like the debuggers do.
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@Joerg Then what it all mean is that : When we have "workbench" name in the task/process name with its 500 counts of CallHookPkt() - we do have only name of process from which this all happens, but not directly : i.e. we don' see there that workbench do call layers.library, or graphics.library, we only see that some process were involved in calling CallHookPkt(). But how can be detect _what_ exactly call it ? I.e. not the process from which we invoke it originally, but what call the CallHookPkt under the hood ? Of course probably the best way will be to use GDB or db101/spotless, and instruction by instruction find out how the way from user application till final CallHookPkt() passed , but maybe it possible to trace without debugger and in more automatic way ? @LiveForIt Quote:
Hook can be simple function pointer, does need to be a utility.library hook.
But then it's not a casual utility-like hook, but a self-made one, the ones we didn't count there. And IMHO most of amigaos4 libs do use CallHookPkt (at least even in old os3 times, ASL library already used CallHookPkt, and even string.gadget too)
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Quote: But ! It can be very well, that most libraries do not use CallHookPkt() directly, but instead, self-made CallHook() from amiga.lib (or so), meaning that it still provide hooking functionality, but not via CallHookPkt() ? Should only be the case if you are using AmigaOS <= 3.x/m68k software, or AmigaOS 4.x ports which weren't fixed. Although CallHookPkt() is an AmigaOS 2.0 function a lot of AmigaOS <= 3.9 software didn't use it but called the h_entry function directly, or used an obsolte libamiga.a function (for Kickstart 1.x compatibility) doing that instead. From the utility.library/CallHookPkt AutoDoc:
This form of transparency comes at a price: h_Entry must not be jumped
to directly, as calling 68k legacy code from native code will result in
a crash, and calling native code from 68k legacy code will result in
native code being interpreted as 68k code, with completely unpredictable
results.
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
I think many libs use CallHook() from amiga.lib, instead of "modern" CallHookPkt() which were created later ? At least intuition for sure (at least on old os3)
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@kas1e
Perhaps devices is its own thing,
|
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@Joerg
But again, we can see only name of process/task, but we can't see from which else it come too. I mean, Workbench can use asl, layers, etc. But in log we will see just "Workbench" task
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@joerg
Hook can be simple function pointer, does need to be a utility.library hook.
|
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@joerg At least i checked it like this:
int a;
ULONG APICALL Patched_CallHookPkt(struct UtilityIFace *Self, struct Hook *Hook, APTR object, APTR message)
{
a++;
return blablalba
}
int main(balbal)
{
bablab
<ctrl+c handler>
printf a;
So it did count all counts to CallHookPkt() and i see none of them coming from anything else than Dos_server and Workbnech. But ! It can be very well, that most libraries do not use CallHookPkt() directly, but instead, self-made CallHook() from amiga.lib (or so), meaning that it still provide hooking functionality, but not via CallHookPkt() ?
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e
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.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
|
Just popping in
|
@MamePPCA1
Personally, I've tried these backup programs before, but end up giving up. Not sure what it was but they can get stuck if a file system has errors. I tend to go back to Workbench even though that has flaws.
Both are old designs and a strange mix. One is 68K so using old DOS functions but simple enough. The other is updated for OS4 but still using an old interface and is slightly confusing to use.
I'd use the older BackUp given the choice. Just needs source and destination. But, you could also just use a tool like DirOpus. That may be the easier option.
|
|
|
|
|
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
