Re: Update on rlbox wasm sandbox crashes

On 10/7/25 6:34 pm, John Ogness wrote:
> Hi Damien,
>
> Thanks for providing these insights!
Happy to share. :-)
> It seems to me that this is where the big-endian/browser community
> should be focussing its efforts: wasm2c generating portable code.
>
> John Ogness

After testing it I agree. It really is a multi layered approach to 
isolation with it being compiled to a virtual binary, decompiled into C 
and then wrapped in another software layer before being compiled again. 
The issue here being the virtual binary in the middle designed for an 
opposite endian.

On that note, last night I confirmed my suspicions were correct. I found 
an issue with a data table related to some stdout handle. It stores 
stdout as some offset which acts an address in the isolated memory space 
that points to this table. Later it reads from the table at that offset 
and because the table is opposite endian the values are all backwards. I 
just confirmed on x64 from same routine that a $05000000 is meant to be 
a $05. I don't know why it insists on writing tables as bytes as if 
trying to hide data. But if it just included the scalar data as a normal 
array or struct, with the value it is supposed to have, it would avoid 
all this endian hacking and would work normally. :-?

Given the macro reverses the same table, I wonder of they meant to 
convert the table to host endian, but made an amusing blunder of 
swapping the whole table instead of each scalar? So either the table 
needs to be fully converted with knowledge of each scalar size. Or table 
reference routines need to swap on the spot. That's what I'm thinking. 
If the endian issues are isolated to this table and wasm2c knows what's 
in it this will be a lot easier to fix. :-)