[Libre-soc-bugs] [Bug 982] Support PowerPC ABI in ISACaller
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Sep 18 18:38:04 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=982
--- Comment #49 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
Sorry I haven't been responsive chaps in the last few days, I was too tired to
work on this.
(In reply to Dmitry Selyutin from comment #30)
>
> Andrey, what'd be the right way to split the activities so that I don't step
> on your toes? I assume the task consists of the following steps:
>
> 1. Update dev-env-setup and openpower-isa with the proper Linux kernel clone
> (easy to handle) and script invocation.
> 2. Extending openpower.syscalls module with the logic to lookup the PPC
> system call on the host.
> 3. Introducing a shim wrapper around syscall, which takes several integers
> and passes them SOMEHOW into the host registers. The only question I have
> there relates to resources.
I kind of get the gist of you're suggesting, although this is starting to go
way beyond my understanding.
The bare minimum I was thinking about, was not even bother with syscalls, and
just use bog standard python methods (like write()) to emulate syscall
behaviour. With some syscalls (like exit(), we can't even use the linux
syscall, because we just want to terminate the program running in ISACaller,
not the python script itself).
How much actual kernel interaction do you need with ISACaller? Isn't printing
to stdout already sufficient for a wide range of applications?
On another note, is there a way to reduce the ISACaller printing without
SILENCE_LOG? SILENCE_LOG takes away most of it, but normal printing is way too
much (don't understand much of it). To me ISACaller is still too much of a
monster, and I'm not sure which files are better to approach (where are the
GPR's/SPR's memory is, how to start/stop the simulator, etc.)
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list