Hi Josef, El 12/03/18 a las 18:19, Josef Stark escribió: > I experimented a bit and after comparing the actual register contents of > R0-R15 inside the child application with the contents of the > Thread_state register backup (R0-R15) that is delivered to my fault > handler, it seems like Genode (or Fiasco.OC or the glue code) delivers > the registers in a strange mapping, where some original regs are mapped > to different regs in the backup, and some do not appear at all. The > mapping is like this: > > Thread_state | Child | Child - Alternative Possibility > --------------------------------------------------------- > R0 | R9 | R7 > R1 | R10 | R4 > R2 | R11 | > R3 | | > R4 | | > R5 | | > R6 | | > R7 | | > R8 | R0 | > R9 | R1 | > R10 | R2 | > R11 | R3 | > R12 | R12 | R5 > R13 | R13 | > R14 | R14 | > R15 | R15 | > | R6 | > | R8 | > > (Alternative Possibility means I couldn't tell which of the two is > actually correct due to equal values. The Thread_state registers that > have no mapping contained values that did not match any of the original > register contents; some of those values appeared in two distinct > Thread_state registers. I assured myself that the child didn't modify > the registers before dumping the contents.) > While this looks pretty strange, I verified the 'mapping' on a few > occasions and after incorporating the mapping into the instruction > emulator/the redundant memory writer, it does what it should, at least > for a limited test case (which doesn't access one of the unmapped > registers). > > I should mention that we use a slightly modified Fiasco.OC kernel and > kernel interface, since in the unmodified Genode 16.08/Fiasco.OC, > calling Cpu_thread_component::state() [1] internally calls > Platform_thread::state(), which does not return the contents of all > registers. Instead our modified Platform_thread::state() calls our own > method all_regs() [2] which does that. The modified Fiasco.OC kernel > source files are [3] and [4] with modifications marked with a comment > mentioning "rtcr". But no remapping or other strange things are done there. > > My guess is that this register magic is not happening in the base-hw > version of Genode (since Vinit instruction emulation is not using any > remapping and still works), but maybe you still have a clue of what is > going on there.
Sorry, but I don't have a glue what the problem is. It looks as if there are issues with your all_regs syscall. Maybe the regs array layout is not as you expect it to be, or the v->mr array gets modified afterwards in the kernel? In your position, I would look into what really happens during the syscall, which values get written to the v->mr and what is done with them. In contrast to FOC, the base-hw kernel was written with the sole purpose to fullfill the requieremts of Genodes Core/Userland in the simplest manner possible and thus, the kernel had support for returning all regs of a thread right from the beginning. Cheers, Martin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main