[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