Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
49 user(s) are online (26 user(s) are browsing Forums)

Members: 0
Guests: 49

more...

Headlines

Forum Index


Board index » All Posts (joerg)




Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


@Hypex
Quote:
That's still too complicated. Given a library call is like this without needing to think about it.
Only works because on m68k the AmigaOS library calls are replaced with inline functions, macros or #pragma, depending on the compiler, which replace the standard stack based m68k ABI with register arguments, and a hidden A6 library base argument, for those functions .

Quote:
So it certainly could have been programmed in.

int32 hookFunc(struct Hook *hookAPTR objectAPTR message)
#include https://github.com/adtools/SDI/blob/master/SDI_hook.h
HOOKPROTO(hookFuncint32APTRAPTR);
static 
int32 hookFunc(struct Hook *hookAPTR objectAPTR message)
{
   ...
}

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


@Hypex
Quote:
The 68K ABI convention is also the same way as the native ABI also uses registers in API calls,
No, it doesn't.
Check for example https://m680x0.github.io/doc/abi.html
For the return value a register (d0 for ints, a0 for pointers) is used, but all arguments are on the stack, none in a register.

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

Except in that case but it can be compiler specific.
It would have been compiler specific if I'd have used something like
int32 hookFunc(__asm(a0struct Hook *hook__asm(a2APTR object__asm(a1APTR message)
which only works with GCC, but using the REG() macro instead works at least with SAS/C, DICE, VBCC, StormC and GCC.

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


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

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

But even on m68k most people didn't use that anymore but something like
ASM SAVEDS int32 hookFunc(REG(a0struct Hook *hook), REG(a2APTR object), REG(a1APTR message))
{
   ...
   return 
result;
}
in h_Entry.

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

It's the same for PPC native code, just in case someone uses useless code like
int32 hookFunc(struct Hook *hookAPTR objectAPTR message)
{
   ...
   return 
result;
}

int32 hookStub(struct Hook *hookAPTR objectAPTR message)
{
   return 
hook->h_SubEntry(hookobjectmessage);
}

struct Hook hook;
hook.h_Entry hookStub;
hook.h_SubEntry hookFunc;


Edited by joerg on 2024/5/23 6:08:42
Go to top


Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


@kerravon
Quote:
int c_Write(void *handle, void *buf, int len)
{
int rc;
rc = fwrite(buf, 1, len, handle);
return (rc);
}
That's wrong and wont work in all cases.
dos.library Write() is an unbuffered I/O function, while C library fwrite() is buffered.
If you want to use C fwrite() for dos Write() you'd have to use
int c_Write(void *handlevoid *bufint len)
{
int rc;
rc fwrite(buf1lenhandle);
fflush(handle);
return 
rc;
}
instead.

Additionally dos.library file handles can't be the same as a C library FILE handle, it's a different abstraction layer.
dos.library BPTR file pointers are more similar to the POSIX int filedes.

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


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

Quote:
OS4 devs says that in OS4, CallHookPkt() and CallHook() are 2 independent functions.
Maybe because it's such a small function that the code size of a uint32 VARARGS68K _impl_CallHook() calling Self->CallHookPkt(), as I wrote in my previous answer, isn't much less then implementing it directly.
It's a very small function anyway, something like
if (IExec->IsNative(hook->h_Entry))
   return 
hook->h_Entry(hookobjectmessage);
else
   return 
IExec->EmulateTags(hook->h_EntryET_RegisterA0hookET_RegisterA2objectET_RegisterA1messageTAG_DONE);
for CallHookPkt() and
uint32 result;
   
APTR message;
   
va_list args;
   
va_startlinear(argsobject);
   
message va_getlinearva(objectAPTR));
   if (
IExec->IsNative(hook->h_Entry))
      
result hook->h_Entry(hookobjectmessage);
   else
      
result IExec->EmulateTags(hook->h_EntryET_RegisterA0hookET_RegisterA2objectET_RegisterA1messageTAG_DONE);
   
va_end(args);
   return 
result;
for CallHook().

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


@kas1e
Quote:
But as they have both CallHookPkt() (non varargs) and CallHook() (varargs) different implementation even today in utitlity.library, it's interesting why they choose to expand with emulator check an CallHookPkt() and not CallHook().
The removed amiga.lib/libamiga.a CallHook() didn't support emulated m68k code, but of course the utility.library one does.

Like with all other VARARGS68K functions, for example the TagItem ones or IDOS->FPrintf() calling IDOS->VFPrintf(), there is not much additional code, it's simply something like
uint32 VARARGS68K _impl_CallHook(struct UtilityIFace *Selfstruct Hook *hookAPTR object, ...)
{
   
uint32 result;
   
va_list args;
   
va_startlinear(argsobject);
   
result Self->CallHookPkt(hookobjectva_getlinearva(objectAPTR));
   
va_end(args);
   return 
result;
}


On AmigaOS <= 3.9/m68k such varargs functions IIRC weren't even in the AmigaOS shared libraries, but instead in the AztecC/SASC/DICE/GCC/VBCC/etc. pragma/inline includes, i.e. for GCC something like:
static inline CallHook(struct Hook *hookAPTR object, ...))
{
   return 
CallHookPkt(hookobject, &(object 1));
}
in inline/utility.h.
But such simple stack hacks don't work on PPC where the first 8 arguments of each type, int, float/double and vector, are passsed in registers, only on CPUs like m68k using the stack for all arguments.

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


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

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



Like, both were deprecated in favor of single CallHookPkt() , so to not have varargs function. Even if they have CallHook() still in utility.library (probably side effect of easy porting from os3 back in times), it all looks like that they want to get rid of Varargs one. Maybe because Varargs ones is potetialy not safe-ones, as can corrupt the stack in some conditions , etc, and that is the reassons they want non-varargs one to be used always ?
It's most likely not related to varargs at all, but that only utility.library CallHookPkt() includes the required check and different way to execute the Hook function depending on if it's emulated m68k code or PPC native code.

The same could have been added in the amiga.lib/libamiga.a hook functions, instead of removing them, but why? It would have been duplicated code, and statically linked code is always bad if you have the same functions in a shared library where bugs can be fixed or new features added without having to recompile all software using it as it's the case for static link libraries such as libamiga.a or the clib2 libc.a.

I don't know if there were usable OS3 utility.library sources which could have been used for the OS4 implementation, but I guess it was the same as with exec (and several other OS3 sources): Useless m68k assembler code reimplemented from scratch for OS4.

Go to top


Re: SoDIMM DDR3 testing on A1222
Just can't stay away
Just can't stay away


@Maijestro
Quote:
Can AmigaOs4.1 access 4/8 GB of memory at all or is the maximum usage 2GB?

For 99% of the software on AmigaOS 4.1 the limit is still 2 GB, using more requires adding support for the "ExtMem" feature in the software.
For example the "RAM Disk:" handler supports it, i.e. for files you copy to RAM: it doesn't use the first 2 GB, which all software can access, but can use the upper 2 GB instead software not supporting ExtMem can't use.

Special note for your QEmu setup: ExtMem isn't supported in the Pegasos 2 kernels, no matter if real or emulated hardware.
I don't know why, but probably differences to U-Boot or bugs in the hardware/DIMM setup of the Pegagsos 2 SmartFirmare for more than 2 GB RAM.

More than 4 GB is theoretically possible even on the old systems (G2, G3 and G4 CPUs support 36 bit physical address space, i.e. 64 GB RAM), but none of the 32 bit hardware (classic Amiga with Blizzard/CyberStormPPC, AmigaOne, Pegasso2) supports it. On the 4x0 CPUs it's IIRC 41 bit, 2 TB = 2048 GB RAM, but I doubt the Sam440/460 supports more than 4 GB.
Only the systems with 64 bit CPUs, X1000, X5000 and A1222, may support more than 4 GB.

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


@kas1e
Quote:
I mean, it didn't looks like for support OS1.x
From amiga_lib.doc.txt CallHook() and CallHookA()
NOTES
    This 
function first appeared in the V37 release of amiga.lib.
Howeverit does not depend on any particular version of the OS,
    and 
works fine even in V34.


Quote:
Maybe issues was all this C compilers (and maybe assembler ones?) asking for things to be on stack, so to make live of assembler programmers easy or something ?
amiga.lib CallHook() is a varargs function using the stack (on m68k) for the message, utility.library CallHookPkt() uses registers with a pointer to the message, similar to TagItem functions (always two versions, one with a pointer to a TagItem array in a register, one using varargs on the stack instead).

However, that doesn't explain why amiga.lib has CallHookA() as well, which is identical to utility.library CallHookPkt() (except for maybe utility.library using 3 registers for the arguments, amiga.lib using 3 arguments on the stack instead, not sure).
The reason for CallHookA() in amiga.lib can only be AmigaOS 1.x compatibility, as written in the NOTES of the autodoc.

Go to top


Re: Tracing of callhookpkt()/callhook()
Just can't stay away
Just can't stay away


@kas1e
Quote:
In other words, there wasn't any reasons to support 1.x code, as there wasn't any hooks at 1.4 times.
After AmigaOS 2.0 was released for at least 5 years, maybe even longer, most AmigaOS software was still built to work on AmigaOS 1.x as well.
Even if there are no Hooks in AmigaOS 1.x itself user code of that time built for both AmigaOS 1.x and 2.x probably used them internally, for example in functions used on AmigaOS 1.x only adding support/replacements for new AmigaOS 2.x features, as well as in the AmigaOS 2.x parts.

Except for AmigaOS 1.x support there is no reason at all to have a CallHook[A]() function in amiga.lib since CallHookPkt() is available in the AmigaOS 2.0+ utility.library.

Go to top


Re: Tracing
Just can't stay away
Just can't stay away


@kas1e
Quote:
So question which noone were able to answer me: why there were needs to create callhook() at all in amiga.lib, when, intuition has already callhookpkt, and all ut needs is callhookpktA(), and be done with it.
CallHookPkt() was added in utility.library V36 (AmigaOS 2.0), using the libamiga.a CallHook() instead was required for software which should work on AmigaOS 1.x as well.

Go to top


Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


@kerravon
Quote:
Oh - thanks for that insight! Maybe there needs to be ANSI escapes to draw such characters, and the terminal is required to put a "*" there if it doesn't support a particular box character.

It would be interesting to know if THIS was the show-stopper.

I don't do such box-drawing myself so didn't realize this could be an issue. I only do C90 plus ANSI X3.64 for microemacs, which doesn't draw boxes.
AmigaOS doesn't even use 7-bit workarounds like <ESC>[ (0x1B 0x5B) for escape sequences (IIRC it's supported for output as well, but not for key input) but the 8 bit <CSI> (0x9B) sequences instead, for example for the cursor up/down/left/right keys for input, for output moving the cursor, changing foreground and background colours, etc.

Go to top


Re: developing amiga 68000 clone
Just can't stay away
Just can't stay away


@kerravon
Main problem is that there is next to no AmigaOS software running in a shell, nearly all uses a GUI.

Of course there are a few exceptions like the VIM editor, originally developed on AmigaOS, or S-Lang and ncurses based ports, for example the slrn usenet newsreader, mutt e-mail client and the w3m web browser, some of which I ported to AmigaOS 20-30 years ago, but there is no advantage using an AmigaOS port of any of them compared to the versions on other OSes.

One of the "problems" compared to MS-DOS is that AmigaOS uses ISO-8859 charsets (ISO-8859-1 on AmigaOS <= 3.9, default on AmigaOS 4.x is ISO-8859-15).
With the code page 437 charset used on MS-DOS it's much easier to create text/shell only software since you can "draw" lines/boxes/etc. with the chars 0xB0-0xDF creating a "GUI" in text-only mode, for example like the MS-DOS version of Norton Commander did.
With the ISO-8859 charsets used on AmigaOS that's not possible.

Go to top


Re: Tracing
Just can't stay away
Just can't stay away


@Hypex
Quote:
did read somewhere that 68K varargs style or simply stacking data was incompatible to PPC.
Alignment of the structs and on the stack is different: 2 bytes on m68k (even for 32 and 64 bit types), on PPC it's at least the size of the data type, for example 4 bytes for int32 and float, 8 bytes for int64 and double.
For the AmigaOS structs that's changed with the #pragma pack(2) (GCC)/#pragma amiga-align (VBCC) at the start and and #pragma pack() (GCC)/#pragma default-align (VBCC) at the end of the OS includes to be m68k compatible.

Quote:
68K and PPC are similar in that they allow for a number of registers. 68K has 15 in all it can use in total but PPC has only 8 GPR for all,
PPC has 29 available GPR registers (+ r1 = stack pointer + r13 = small data pointer + r2 = baserel pointer = 32 total), m68k has 14 (+ a7 = stack pointer + a4 = small data pointer = 16 total, but 8 are for integers only and 6/8 only for pointers).
IIRC the standard C ABI for m68k only uses 2-6 registers for argument passing depending on the data type of the arguments (d0 and d1 for 32 bit integers or d0+d1 for one 64 bit integer, a0 and a1 for pointers, fp0 and fp1 for float/double), on PPC 8-24 registers are used (8 GPR + 8 float/double + 8 vector).

Quote:
so some fully registerised 68K functions are less efficient and stacked in PPC ABI.
I don't see how that should be possible, neither in the standard C ABI, not when using REG(reg) arguments using more than the standard number of registers for arguments, nor with assembler.


Edited by joerg on 2024/5/10 18:33:33
Edited by joerg on 2024/5/10 18:34:48
Go to top


Re: sam460: takeover control by putty ?
Just can't stay away
Just can't stay away


@kas1e
Quote:
Yeah, it works for current session (When i am in uboot shell already) , but , when i reboot, i can't "esc" from putty's keyboard to go to the uboot , neither from usb keyboard. But i definately have "serial" for both stdin and stdout.
Setenv only changes variables for the current session, if you want to make it permanent use
setenv stdin serial
setenv stdout serial
saveenv

Go to top


Re: Tracing
Just can't stay away
Just can't stay away


@kas1e
Quote:
There is the output of all CallHookPkts with their stacktraces, when i just run simple hello world (no CallHookPkt calling from test case, just hello world via casual printf() from libc):
C library printf(), at least the newlib one, is no "problem", but the OS printf() like functions (IDOS->Printf(), IUtility->SNPrintf(), IExec->DebugPrintF(), etc.) are more or less all based on IExec->RawDoFmt() which is replaced (SetMethod()) by locale.library when it's started with (something similar to) ILocale->FormatString() which uses a Hook for the putCharFunc and you should get a CallHookPkt() call for each char.

Quote:
Then stacktrace massively overwrite other outputs (debugpritnf for name of task and amount of calls). Is it expected that it didn't work when different tasks involved, and not a single one like we did with signals ?
That's normal, debug output writes one char after another to the serial port, and if there are several tasks with debug output at the same time and task switches happen you get a mix of them.
Maybe using something like
IExec->Forbid();
IExec->DebugPrintF("[%s] CallHookPkt call # %d\n",patched_task->tc_Node.ln_Namecallhookspkt_counts++);
IExec->Permit();
in the patch and Forbid()/Permit() around the stack trace DebugPrintF() could help.
You still get a mix of different debug output, but at least complete lines for each task and not chars from different tasks in the same line.

Go to top


Re: My Amiga Projects
Just can't stay away
Just can't stay away


@TheMagicSN
You can get similar debugging features on AmigaOS 3.x/m68k by installing and using about 10-20 debugging tools (Sushi, SegTacker, MuGuardianAngel, MemTrace, EatMem, etc.), but even with all available AmigaOS 3.x/m68k debugging tools installed you still get less information than on plain AmigaOS 4.x ("just" (Grim)Reaper) without using any additional debugging tools like GDB, Spotless, etc.

Go to top


Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
Just can't stay away
Just can't stay away


@white
C:BootLoader is only used on classic Amigas/WinUAE.

I'm not sure if a SWAP partition is usable on a QEmu Pegasos2 (with -m 2048) at all. Unless something radically changed in AmigaOS 4.x in the last 20 years only the first 2 GB of the 32 bit virtual address space are usable for RAM (incl. SWAP partition), the upper 2 GB are used for the PCI(e) address space.

A real Pegasos2 is AFAIK limited to 1 GB RAM and with a SWAP partition you can extent it to 2 GB.

On other systems more than 2 or 4 GB physical RAM can be used with the ExtMem feature, but from https://wiki.amigaos.net/wiki/Exec_Extended_Memory
Quote:
Pegasos 2 Warning
The extended memory feature currently does not work on the Pegasos II platform. Programmers are still encouraged to use ExtMem but may need to add an exception for the Pegasos II platform. Use IExpansion->GetMachineInfo() to verify which platform your code is executing on.


Quote:
I have not currently removed the SWAP
If I remove it, will it lead to invalidation of the disk ?
As long as you don't change anything in other partitions (moving, resizing, etc.) just deleting the SWAP partition is no problem.

Go to top


Re: Tracing
Just can't stay away
Just can't stay away


@kas1e
You are mixing signal bit numbers with signal masks.

In the patch replace
IExec->Signal(&main_task->pr_Task<< portsig);
by
IExec->Signal(&main_task->pr_Taskportsig);


You could remove the unused port and message parts and simply use something like
int8 portbit IExec->AllocSignal(-1);
if (-
== portbiterror;
else 
portsig 1UL << portbit;
in main() to allocate a signal.

Quote:
portsig = 0x00000010
mainPort->mp_SigBit = 0x00000004


WTF ? :) Shouldn't it be the same ?
SigBit is the 8 bit signal bit number (0-31), portsig a 32 bit signal mask: 1 << SigBit;

Go to top


Re: Tracing
Just can't stay away
Just can't stay away


@kas1e
Quote:
with global set as before for 150 CallHookPkts i only have 12 stacktraces
Because you didn't stop the patched task and wait until the main() task is done with the stack trace.
It can be done in different ways, sending messages, or SupendTask() in the patch and RestartTask() it in the main task after the stack trace is done, but using signals is the easiest way.

Quote:
So i need something like - 1 CallHookPkt happens - 1 stack trace provides.
Sending and waiting for signals does that.

Go to top



TopTop
(1) 2 3 4 ... 88 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project