[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 #35 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #34)
> (In reply to Dmitry Selyutin from comment #32)
> critical information. is that known? i may have missed it
> > 
> > Yep, I implemented it. 
> 
> i saw.  the commit is *tend* of thousands of lines long which is
> precisely why the hard rule exists, as it is massively overloading
> both my server and also my tablet.  it was 4 minutes to load the diff.

That's why I prefer $(git show), not URL's. :-) Anyway, that's rolled back.


> > These are basically useless w/o information on
> > arguments. Check Ctrl+F on this bug page for SYSARGS. :-)
> 
> ok i see. ok that's auto-parseable. that's great, because autogenerating
> the actual calls *even if "safed"* like in qemu-user, shouuuld be
> reasonably straightforward.
> 
> i don't know how easy it would be to grab the size of data structs
> for each object out from somewhere? even if it's done by hand
> (or put into a lookup dictionary).

Let's consider an example of just one system call. Even for `fstat`, there are
3 system calls with three different structures. That's only for i686; I'm not
even speaking of compat syscalls. And I don't even mention stat, lstat,
fstatat, fstatfs et al. They all have their multiple system calls. Recently
they introduced statx, which should finally fix it (again).
Newer architectures have less of this nonsense, but still do. PPC has several
fstat too: ppc32 supports at least 3 (just fstat), ppc64 has 2 (one of them is
compat). There are other issues related to passing 64-bit integers too.
That's what happens when you attempt to guarantee userspace ABI but allow users
to operate by other means than via libc wrappers.


> yes. sigh. but there *might* be enough information to actually
> autogenerate (dynamic, runtime) everything.

There is, but, unless you pass the same options used to build the kernel and
likely build it indeed, it's damn complicated. At the very minimum you have to
have the same uAPI files as the kernel generates based on tons of options. The
best option is to take from other project; qemu user emulation should've done
it.


> > Here comes a microkernel in ISACaller, lol.
> 
> userspace emulation of POSIX, in python... yes!

No, this is wrong. POSIX has no idea of system calls. That's not their level of
abstraction. They operate in terms of API, and it just happens that many OSes
choose to implement this API via syscalls. Quite an unfortunate tradition,
frankly speaking; I'd prefer simpler building blocks. POSIX is powerful, but
not a good candidate for kernel<->userspace cooperation. It serves a different
purpose.


> > Hard to start, annoying to invent a reusable code, but still pretty doable
> > and straightforward.
> 
> ohh fer goodness sake. i just realised, any memory allocated
> (for the syscalls) you can't just discard it, you actually *need*
> to keep it under a lookup table.
> 
> so when you get a shared memory lock you absolutely cannot just
> blithely allocate a new area buffer.
> 
> ok this is complicated.
> 
> we *may* need to make a special version of sim.mem that *actually is
> backed by a mmapped/malloced area of memory*, such that there is a
> *DIRECT* one-to-one relationship between the addresses of the
> emulator and when the syscalls take place.
> this would have the advantage of not needing to map in/out in the
> syscalls, you just literally pass the pointer-register to the syscall.

It makes life easier, indeed. Still there will be mappings for... mmap itself.
Basically to make these work you have to invent poor man's MM.


> there is a way to call syscalls...
> 
> https://stackoverflow.com/questions/37032203/make-syscall-in-python

I already told about it few comments ago. Yes, Linux libc wraps syscalls in
syscall(2), converts codes to errno, and this is present in ctypes too (thus
ctypes.get_errno() suggestion). On amd64 (and I think on most modern 64 archs)
it's as tiny as just changing some of the registers due call/kernel-syscall
conventions.


> i *have* seen something that allows *direct* function calling... oh god
> https://dev.to/adwaithrajesh/calling-asm-function-from-python-part-maybe-0-
> 46e1

No need and no point. In addition to complications of passing the parameters,
you'll have to support different calling conventions. libc already takes care
of that.


On the overall in separate comment.

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