Re: Creating tasks and the l4_task_map function

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