Who's Online |
90 user(s) are online ( 69 user(s) are browsing Forums)
Members: 0
Guests: 90
more...
|
|
|
|
|
Re: Tracing
|
|
Home away from home 
|
@joerg
I am completely looses now :( Aren't we tried to use messages/signals whatever for exactly purposes to send ProcessID from the patch to the main ? In your example, processID aren't transferred, which was the whole purpose of last 2 pages :)
Aren't with your example we simply return to globals again ? Because i had to define patched_task and main_task as globals out of the functions, and we then back to the same as before (process_to_inspect = process); with only one difference that we add signals for wait and send now around.
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away 
|
@Hypex Quote: I noticed those VARARGSS68K but I didn't see why they were necessary. Any emulation of 68K var args is internally to the emulators so shouldn't need to be exposed. Would have required 2 different implementations for all varagrs TagItem functions: One which can be called from PPC native code and a different one which can be called from emulated m68k code. Quote: Aside from that varargs are a common function practice in portable C code that can run on x86 or PPC and others so varargs never looked 68K exclusive to me. The C parts are common, but the implementation of varargs is CPU specific. IIRC on m68k everything is put on the stack, but on PPC the first 8 integer, FPU and AltiVec arguments are passed in registers and only if there are more the stack is used. VARARGS68K doesn't use the standard PPC varagrs method but only the stack, exactly like on m68k, and a single function can be called form both PPC native and emulated m68k code.
|
|
|
|
|
|
Re: 2024 - April - Space Cadet Pinball
|
|
Quite a regular 
|
The competition has now ended.  Thanks to all for playing! Congratulations to the winner, 328gts!
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Stop allocating anything in your patched function, your patch code is running in a foreign tasks and you don't know in which state it is. Allocating anything, memory, ports, messages, etc., can for example break Forbid() since the memory, page, etc. allocator may have to wait for exclusive access with a mutex. As long as you only want to debug a single task messages aren't required, sending signals is enough. In the patch you can't allocate signals, for example fails if all are used already, use SIGF_SINGLE instead. For the main task you can allocate a signal. Something like patch function
patched_task = IExec->FindTask(NULL);
IExec->SetSignal(0, SIGF_SINGLE);
IExec->Signal(main_task, 1 << portsig)
IExec->Wait(SIGF_SINGLE);
main()
if (signal & portsig)
{
IExec->DebugPrintF("port signal for 0x%2508lx\n", patched_task);
stack trace, etc.
IExec->Signal(patched_task, SIGF_SINGLE);
}
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@Hypex Quote:
So the simplest way if avoiding the reply port would be this:
Simple crashed right after i got "mainport received: ProcessID = 191" and code do "IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);". I.e. processID messages from patched hook fine first time, we receive it, print the value, but then, when we need to answer we crash. That how currently it looks like: part from patched callhookpkt:
if (&process->pr_Task != NULL)
{
if (hookstack != NULL)
{
struct ProcessIDMessage *message = (struct ProcessIDMessage *)IExec->AllocSysObjectTags(ASOT_MESSAGE,
ASOMSG_Size, sizeof(struct ProcessIDMessage),
ASOPORT_AllocSig, FALSE,
ASOPORT_Signal, SIGB_SINGLE,
ASOMSG_ReplyPort, NULL,
TAG_DONE);
if (message != NULL) {
message->processID = process->pr_ProcessID; // Get the process ID here
}
IExec->SetSignal(0, SIGF_SINGLE);
IExec->PutMsg(mainPort, (struct Message *)message);
IExec->Wait(SIGF_SINGLE);
IExec->FreeSysObject(ASOT_MESSAGE, message);
IExec->DebugPrintF("CallHookPkt call # %d\n", callhookspkt_counts++);
}
}
}
Part from main():
if (signal & portsig)
{
IExec->DebugPrintF("port signal\n");
while(receivedMessage = (struct ProcessIDMessage *)IExec->GetMsg(mainPort))
{
IExec->DebugPrintF("mainport received: ProcessID = %lu\n", receivedMessage->processID);
//IExec->ReplyMsg((struct Message *)receivedMessage);
IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);
}
}
|
|
|
|
|
|
Re: Tracing
|
|
Not too shy to talk 
|
@kas1e Quote: You say i need local port to give a reply port, but I can avoid it, while can't (as i need it), but instead create it by some other than AllocSysObjectTags way as it have “allocation overhead” ? Or what you mean exactly ? Sorry was typing reply in a rush before bed time. Okay so by local port I meant a port local to your patched function. You don't necessarily need a port, it's just the messaging system is designed in a two way fashion, so a message is sent to a task and that task replies the message back when it has finished. The port doesn't need to be a normal port either where a message is sent back to. A message can be bounced back as a signal or even trigger a software interrupt as you've seen. By “allocation overhead” I mean needing to allocate memory on the fly. So by comparison local variables are less overhead as they just get reserved on the stack and avoid an API call. I'm most likely just being pedantic as I would avoid any system calls allocating resources inside a debug routine. Given OS4 has the slab allocator it's probably not such a big deal. Quote: As i understand it, you still suggest to use for AllocSysObjectTags also ASOPORT_Signal when allocation for message, and this mean i can not create second reply port, and handle it without ? (sounds strange!) But what about “allocation overhead” which you mention, then if AllocSysObjectTags() still should be used for ? Sorry, I see I've confused you. In this case you allocate a message. But it needs a reply port allocated as well. The reply port can just be specified as a signal using the ASOPORT_Signal tags as you have set up. But you will need to allocate a port with ASOT_PORT type and those tags. However, since you are only messaging your own task, you can just skip the reply port all together. It can be set to zero in the message, in which case it will just mark the message as free when replied back. In this case, you can simply skip another port, and just signal back directly. When your main task has finished with the message just grab the process ID from the ProcessIDMessage and signal it back. Quote: The main()'s code is not changed, of course. Hope you wasn't mean that i need to change that too and fully rewrite it to handle new sort of signal without receiving a reply ?:) It will need to bounce it back. You can use the ReplyMsg() mechanism which will need a port attached. Or just simply signal back with a SIGF_SINGLE in this case. That might be best in this case. It avoids setting up a port and you can just use a preset signal. Quote: And where is FreeSysObject() in your example ? Should't it be right after Wait(SIGF_SINGLE) ? Oh yes it should. I just focussed on the message and waiting for signal to go ahead and continue. Quote: ps. Never touched anything with all this messages, but after reading wiki were under impression that for communicate between 2 tasks i need one single port , in which i do this communication by messages, not that i need different port for each messages which should be send from one task to another.. In the common case two ports will be involved. For source and destination. Source sends to destination, which then replies it back to source when finished. So the simplest way if avoiding the reply port would be this:
IExec->DebugPrintF("port signal\n");
while(receivedMessage = (struct ProcessIDMessage *)IExec->GetMsg(mainPort))
{
IExec->DebugPrintF("mainport received: ProcessID = %lu\n", receivedMessage->processID);
//IExec->ReplyMsg((struct Message *)receivedMessage);
IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);
}
|
|
|
|
|
|
Re: 2024 - April - Space Cadet Pinball
|
Posted on: 5/7 22:54
#187
|
Just can't stay away
|
<Bumpy> This competition should probably be wound up and the result list revised - I was not the winner ultimately  . Best regards, Niels
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: 5/7 21:18
#188
|
Not too shy to talk
|
@Spectre660
Nova Bridge is Warp3D support for a Radeon HD cards? It would make all old games work.
But before I buy it, I would like to test this more. I need games that support Warp3D Nova if I have figured it correctly?
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 20:30
#189
|
Home away from home
|
never mind
|
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
|
|
|
|
Re: Tracing
|
Posted on: 5/7 20:15
#190
|
Home away from home
|
@balaton Quote:
. or maybe in the hooked function call suspend self after sending the message and from the main task call restart for the process ID that was passed in the message, then you won't need either a reply message port nor a signal.
That looks like the way to go , and sounds more easy!
|
|
|
|
|
|
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
|
Posted on: 5/7 20:06
#191
|
Quite a regular
|
@smarkusg Quote: But it is also interesting to compare QEMU versions.
For me in this test, QEMU8 is about 1-2 seconds faster than the new Qemu9 Is that consistently so or you just happened to get different measurements or something else is changed on your system between these versions? If this reproduces consistently now with two QEMU versions and you want to find the cause then you could try to bisect which commit made it slower. As the test is automated you may even be able to script that and let the bisect run without intervention so you don't have to compile and test a lot of versions by hand. But 1-2 second may be within the variation that you get by running the test multiple times on the same QEMU version. Testing this on macOS with M1 where you sometimes get faster and slower runs may not be the best so maybe should be tested on something more stable where that issue does not happen.
|
|
|
|
|
|
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
|
Posted on: 5/7 19:54
#192
|
Quite a regular
|
@joerg OK so basically buffers is a metadata cache, not related to caching file data but only directory entries so its size probably should be related to how many files are stored on the partition and how many of them are expected to be open at the same time. So it can be lower for archive volumes or volumes with large files but should be higher for sys or partition with many small files that are accessed frequently. For swap will it be ignored whatever is set there or it's allocated but unused? If it's not allocated then it does not matter and can be left to default. If I got this correctly. Quote: (I added support for SWAP partitions in diskcache.library and the required changes in the kernel about 20 years ago, but AFAIK it was never used.) It seems a bit pointless to cache swap because its purpose is to remove pages from memory so copying a page over to some other part of memory does not seem to be what it should do. Either the page should be kept or swapped out so not much point to put it in cache which would just take space from file system data that the cache is meant to hold. Maybe that's why it wasn't used.
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 19:43
#193
|
Quite a regular
|
@kas1e
Your hook function runs in the caller task while your main runs in your own task. You have to stop the caller after messaging the main task until the main task finishes collecting the stack trace otherwise the caller continues and may exit or will not be at the place you want to trace. There are several ways to do that:
1. Reply with a message, the caller needs a message port for that in addition to the main's message port where you call it.
2. Wait for a signal, then the main task needs to raise the signal (don't know what's the corect term for that in AmigaOS) once finished to make the caller continue.
3. or maybe in the hooked function call suspend self after sending the message and from the main task call restart for the process ID that was passed in the message, then you won't need either a reply message port nor a signal.
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 19:15
#194
|
Home away from home
|
@Hypex Thanks for the answer, but I need some clarification: You say i need local port to give a reply port, but I can avoid it, while can't (as i need it), but instead create it by some other than AllocSysObjectTags way as it have “allocation overhead” ? Or what you mean exactly ? As i understand it, you still suggest to use for AllocSysObjectTags also ASOPORT_Signal when allocation for message, and this mean i can not create second reply port, and handle it without ? (sounds strange!) But what about “allocation overhead” which you mention, then if AllocSysObjectTags() still should be used for ? Then i tried like this, and while it didn't crash, it didn't work, it just stuck on the first receive.
struct ProcessIDMessage *message = (struct ProcessIDMessage *)IExec->AllocSysObjectTags(ASOT_MESSAGE, ASOMSG_Size, sizeof(struct ProcessIDMessage), ASOPORT_AllocSig, FALSE, ASOPORT_Signal, SIGB_SINGLE, TAG_DONE);
if (message != NULL) {
message->processID = process->pr_ProcessID; // Get the process ID here
}
IExec->SetSignal(0, SIGF_SINGLE);
IExec->PutMsg(mainPort, (struct Message *)message);
IExec->Wait(SIGF_SINGLE);
The main()'s code is not changed, of course. Hope you wasn't mean that i need to change that too and fully rewrite it to handle new sort of signal without receiving a reply ?:) And where is FreeSysObject() in your example ? Should't it be right after Wait(SIGF_SINGLE) ? ps. Never touched anything with all this messages, but after reading wiki were under impression that for communicate between 2 tasks i need one single port , in which i do this communication by messages, not that i need different port for each messages which should be send from one task to another..
Edited by kas1e on 2024/5/7 19:43:13
Edited by kas1e on 2024/5/7 19:45:56
|
|
|
|
|
|
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
|
Posted on: 5/7 16:23
#195
|
Just can't stay away
|
@balaton
It's the same for all file systems, but since the "buffers" only cache meta data blocks of the file system, not data blocks of files, a disk cache like diskchache.library.kmod used by SFS and JXFS, fs_plugin_cache for FFS, or internal ones like in NGFS and in NTFS/FAT/etc. (probably all FUSE/Filesysbox based ports) which cache all blocks makes it even faster.
For FFS there is a special exception: On DOSType DOS\0, DOS\2, DOS\4 and DOS\6 partitions, which probably nobody uses, file data blocks have a header with a checksum, leaving only 488 bytes for the actual file data on 512 byte blocks, and are cached by the "buffers" as well.
All other AmigaOS file systems I know, as well as the other FFS DOSTypes like DOS\7 (probably the only one used by 99.9% of the users), use the complete block for file data blocks and don't cache it with "buffers".
There is no swap file system, creating a partition with DOSType SWAP just reserves space for it on the HD, the pager uses direct 4KB (page size) device read/writes within it's bounds without any caching.
(I added support for SWAP partitions in diskcache.library and the required changes in the kernel about 20 years ago, but AFAIK it was never used.)
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 16:08
#196
|
Not too shy to talk
|
@kas1e Quote: 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 :( Unless the function prologue is on the stack frame no it cannot be known exactly. An exact address in the interface can be matched to that offset easily and a name found. Well, after walking a whole list, which is one way about it. With an offset not matching an exact function jump, then it's harder and looking for closest in jump table. So bit of work. And it still can be a best guess to pin point it. Quote: So with that, once i reach first time patched CallHookPkt, and it send the message i simple crashes. If i add (for sake of tests) some Delay(5) in this part, i can see that my ProcessID always 155, and that seems whole messaging combo didn't works as expected. But i surely miss something trivial.. You've done two funny things and perhaps even three.
struct ProcessIDMessage *message = (struct ProcessIDMessage *)IExec->AllocSysObjectTags(ASOT_MESSAGE, ASOMSG_Size, sizeof(struct ProcessIDMessage), ASOMSG_ReplyPort, mainPort, TAG_END);
Aside from the allocation overhead this would be fine, except for one thing. You've set the reply port as your main port. When your main task replies it back it will be endlessly sent back to your main task! You need a local port to give it a reply port. The info will be in the SDK. Now you can avoid creating a reply port by using ASOPORT_Signal in the tags. One tag you will need to give and you can just supply a signal. You will need a signal. You don't know if all signals are taken so it might break getting another one. Just avoid it and use SIGF_SINGLE. Free for single use.
IExec->PutMsg(mainPort, (struct Message *)message); IExec->FreeSysObject(ASOT_MESSAGE, message);
You didn't wait for the message to be processed!  So was this hard crash? Sending a message then instantly freeing memory tends to freeze OS. PutMsg() is very senstive. So you need to wait for that reply. That be a reply port which will overcomplicate it. Or just specify a signal and simplify it. I like this way.
IExec->SetSignal(0, SIGF_SINGLE);
IExec->PutMsg(mainPort, (struct Message *)message);
IExec->Wait(SIGF_SINGLE);
https://wiki.amigaos.net/wiki/Exec_Signals
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: 5/7 16:04
#197
|
Quite a regular
|
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: 5/7 15:48
#198
|
Not too shy to talk
|
Club 3D Radeon HD 7770 GHz Edition CGAX-7772C does work. Now I need to test it. I do have a Enhancer Plus for OS4 installed, but none of old games used to work Radeon 9250 does not work. I renanamed MiniGL.library as I thought it might be a problem and it doesn't work Radeon HD 7770 any way, but that didn't fix problem. What else I need to install / delete to make Enhancer Plus 3D drivers to work? I ques I need to download correct versions of games, to make them support: Open GL ES 2.0 v1.12 Warp3D Nova v1.34 https://www.amiga-shop.net/en/Amiga-So ... for-AmigaOS-4-1::765.htmlWhat would be good way to test performance? https://youtu.be/MWPsmwVkjsM
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 15:31
#199
|
Not too shy to talk
|
@joerg Quote: At least for 99% of the OS4 code doesn't use direct function calls but always goes through the interface of the library. That would be rather inefficient and slow it down. In particular Intuition used to call internal functions. I used to peek and poke a lot. Being C it stacked a lot of parameters and using internal functions avoided stacking registers. But if OS4 doesn't call internally the same way then it will incur the double direction of jump table calls OS4 gets criticised for. Quote: 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. I noticed those VARARGSS68K but I didn't see why they were necessary. Any emulation of 68K var args is internally to the emulators so shouldn't need to be exposed. Aside from that varargs are a common function practice in portable C code that can run on x86 or PPC and others so varargs never looked 68K exclusive to me.
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 15:23
#200
|
Not too shy to talk
|
@LiveForIt Quote: I don’t know why you want your code to have more likely bugs. Well, I haven't started doing it yet, but it's the next best thing to a union. Quote: now image you pointer is NULL, first is offset 0, 2en is offset 4, now image if member is 2en. Obviously to avoid that the "ptr" would be tested as being valid first. Quote: 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. A new member can't be added because a Task must remain static. Process can be extended but a Process is always a subclass of Task and the Task superclass cannot be changed. In any case this works because the first member of a Process is a Task. The same way it can work if it was passed to a function expecting a Node and the Node field specified.
|
|
|
|
|
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
