[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 22:57:23 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=982
--- Comment #37 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #35)
> (In reply to Luke Kenneth Casson Leighton from comment #34)
> > 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.
cavatools cheats, by overriding malloc realloc and free.
actually i believe it just makes free() a stub (saves complications)
if going down this route (a new sim.mem that *actually* reads/writes
to an actual area of malloc/mmao'd userspace memory) it will be
necessary to allocate it at a fixed address of a fixed size.
some hints lead to mmap with MMAP_FIXED and also mremap
https://stackoverflow.com/questions/19945350/allocate-a-memory-chunk-at-a-specified-address-in-linux-kernel
https://stackoverflow.com/questions/6446101/how-do-i-choose-a-fixed-address-for-mmap
the reason for picking a fixed address is so as to be able to compile
static binaries at a pre-arranged address.
i would greatly prefer exploring this route first and see how far it
gets rather than literally writing every syscall emulated in python.
> 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 think we both understand what goes on, you happen to know more
details more readily, with more first-hand experience. always a good thing.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list