[Libre-soc-bugs] [Bug 982] Support PowerPC ABI in ISACaller
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Sep 18 08:59:03 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=982
--- Comment #42 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #41)
> (In reply to Jacob Lifshay from comment #39)
>
> > and then add the base address of that block to all simulated memory
> > operations.
>
> this is the bit that (a) requires identifying all memory buffers for
> all syscalls (which is a stowstopping amount of work for the
> available budget)
you're misunderstanding -- there's *one* block used for *all* simulated memory
regardless of if we're running a syscall rn or not, read/write syscalls are
passed a pointer pointing inside that block.
> and (b) does not work for code that relies on
> address-offsets *in code*.
all *in-code* address offsets are already handled by python for the simulator
(well, if we had used a bytesarray instead of a dict for simulated memory,
since python adds the index to the bytesarray's base address).
the only time when manual offsetting is necessary is when python doesn't do it
for you -- when manually calling raw c syscall wrapper functions.
>
> all *load store* operations executed would need offsetting... *if* they
> were allocated by a syscall, but not otherwise?
no, they're always offset -- transparently, by python. you just access mem[123]
and python accesses byte *(123 + mem.the_buffer_ptr), since that's how array
indexing works.
> this is hopelessly
> impractical to consider.
>
> even (a) is too much work which is why cavatools directly maps
> the guest program into host memoryspace (one-to-one and onto)
> then overrides malloc and free.
cavatools is written in C/C++ where direct memory read/wrires are just a
pointer dereference away. ISACaller is written in python, where indexing into
an bytesarray (or other buffer object, in our case, a mmap object) is the
default way to access raw memory.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list