[Libre-soc-bugs] [Bug 982] Support PowerPC ABI in ISACaller

[bugzilla-daemon at libre-soc.org]

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

--- Comment #50 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Andrey Miroshnikov from comment #49)
> Sorry I haven't been responsive chaps in the last few days, I was too tired
> to work on this.

Hi Andrey, no problems at all! I hope you got some rest.


> 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).

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. 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. :-)


> How much actual kernel interaction do you need with ISACaller? Isn't
> printing to stdout already sufficient for a wide range of applications?

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.


> 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 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).

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