Hi Paul,
On Sun Aug 21, 2022 at 00:18:57 +0200, Paul Boddie wrote:
On Monday, 18 April 2022 23:26:03 CEST Adam Lackorzynski wrote:
On Tue Apr 12, 2022 at 01:09:40 +0200, Paul Boddie wrote:
This might just sound like me complaining, but I also have some concerns about being able to verify the behaviour of some of the code. For example, I recently found that my dataspace implementation was getting requests from a region mapper/manager with an opcode of 0x100000000, which doesn't make any sense to me at all, given that the dataspace interface code in L4Re implicitly defines opcodes that are all likely to be very small integers. At first I obviously blamed my own code, but then I found that in the IPC call implementation found here...
pk/l4re-core/l4sys/include/cxx/ipc_iface
This was obviously...
pkg/l4re-core/l4sys/include/cxx/ipc_iface
...if I explicitly cleared the first message register before this statement...
int send_bytes = Args::template write_op<Do_in_data>(mrs->mr, 0, Mr_bytes, Opt::Opcode, a...);
...then the opcode was produced as expected again.
Which does not fully make sense to me because the message registers seem to be written from 0 on. Anyway, do you have an example maybe?
I just spent quite some time seeing errors like this...
ext2svr | L4Re[rm]: mapping for page fault failed with error -39 at 0x1002fbc00 pc=0x10b7804 ext2svr | L4Re: rom/ext2_server: Unhandled exception: PC=0x10b7804 PFA=0x1002fbc00 LdrFlgs=0x0
-39 being -L4_EBADPROTO (unsupported protocol), of course.
And then I remembered that there was some curious IPC-related problem I had encountered a while ago. It turns out that it was this again, and since I had obtained a fresh checkout of the L4Re code and had forgotten that this could be a problem, I had revived it! Introducing my workaround eliminated the error.
Do you have any ideas as to why the first message register gets corrupted?
No, still not. Any chance I could see a small example of this?
Adam