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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Sep 17 20:26:49 BST 2023


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

--- Comment #32 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #31)
> (In reply to Dmitry Selyutin from comment #30)
> > Yeah, since git (almost) never forgets, I've already dropped the generated
> > file. The link's still actual anyway (I committed a revert), so you might
> > take a look.
> 
> i did. it's cool. would be nice to know what the function parameters are,
> from somewhere. or at least the number of arguments, that's the most
> critical information. is that known? i may have missed it

Yep, I implemented it. These are basically useless w/o information on
arguments. Check Ctrl+F on this bug page for SYSARGS. :-)


> sim.gpr (or, self.gpr)
> sim.mem (or, self.mem. look in mem.py)
> as in: the implementation of write() would be done *by hand* by:
> 
>     fd = self.gpr(3)
>     buf = self.gpr(4)
>     count = self.gpr(5)
>     actual_buf = bytes()
>     for i in range(count):
>        actual_bytes.append(self.mem.ld(buf+i, 1) # something like that
>     self.gpr(3) = sys.write(fd, actual_bytes)

Aha, good enough to go. A temporary buffer for passing into the host syscall
then. On a per-syscall basis, unfortunately.


> siiiigh, yeeeees. i had a think and i don't believe the cavatools trick will
> work in ISACaller: instead we will have to *literally* implement the syscalls
> one by one.
> 
> and errno somehow will need to get created/emulated/set, no idea how to do
> that.

Thanks God even as bad OS as Linux doesn't have this idiotic errno concept in
kernel. They return a negative result to represent the error. That is, kernel
returns -EINTR, and the userspace moves it to errno. "syscall" does the same
stuff though, so we'll likely have to pick this from ctypes.get_errno().


> > I assume this needs a trap mechanism by system call identifier in simulator.
> > Am I right?
> 
> yeeeees - i did describe it somewhere, you need to "spot that a jump to
> address
> 0xC00 has been made". normally this would ACTUALLY contain (in a linux
> kernel)
> an ACTUAL implementation (binary code) of an ACTUAL systemcall/OS
> implementation
> however just like in riscv-spike and cavatools we are going to "hack it",
> by enabling an option to ISACaller that just goes "if PC == xyz call this
> special function instead of trying to execute instructions *AT* that address"
> 
> all quite dreadful but pretty standard - qemu, spike, cavatools - they all
> do it.

Here comes a microkernel in ISACaller, lol.


Hard to start, annoying to invent a reusable code, but still pretty doable and
straightforward.

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


More information about the libre-soc-bugs mailing list