[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 20:03:33 BST 2023


https://bugs.libre-soc.org/show_bug.cgi?id=982

--- Comment #51 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Dmitry Selyutin from comment #50)
>
> Part of the issue is that you still must detect what exact syscall is being
> passed (or, well, rather trapped by) ISACaller. So at the very minimum you
> need guest syscall table. Since we're going to route (at least some of)
> these to the host, we'll likely need host syscall table.

You're right, thanks for doing that table btw.

> We also need a
> mechanism to make both cooperate: shared memory, system call ids and
> arguments translation, fd tree, etc. etc. I've mostly just prepared a ground
> to dig. :-)

Indeed, and again thanks for that. I'll just need to re-read those earlier
comments by Luke and Jacob on memory, eventually will sink in :-)

> The answer really depends on the overall future of ISACaller and cavatools.
> If we go till the end of this road, this is basically the same as QEMU user
> mode (I know, I know, hardly comparable, but partially, in a spirit). For
> now, however, I want to have some mechanism which provides a basis for doing
> this.

I guess it's in our interest to (eventually) support a wide range of syscalls.
When ISACaller is sufficiently optimised (into C) then running whole
applications might actually become viable. And perhaps the efforts of that
could work into cavatools.

> You should ask Luke. :-) I personally think that the idea to debug via print
> is good as long as this debug is not committed to the repository (in fact, I
> almost always debug by prints; but almost never commit this debug).

Yes, print statements have helped more times than I can count...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list