Re: Firefox 133 test package for ppc64
On 15/5/25 3:10 am, Ken Cunningham wrote:
> At present, not from an SSD. It has been working OK until these
challenges.
>
> I guess it's about time to repurpose one of my other SSDs to this
system. I'll find one of the older, slower ones from the junk box that I
took out of another system during an upgrade, and hopefully it will be
compatible.
>
> Otherwise this is not going to be pleasant.
I've got a 1TB Samsung HDD that's been in service over ten years now and
still going strong. But I was gifted an SSD, just a 480GB. So thought I
would put it to use as a dedicated Linux HDD and moved most of my Linux
volumes over.
> So far I have not got into debugging remotely from another system
like that. I'm not sure what method would work best for my Apple Dual G5
PowerMac 7,1 (I recall it's a 7,1 -- hopefully that is right). I know
these systems can do that, I read about kernel debugging in MacOS using
two machines. I think those instructions were with an ethernet cable,
but that is MacOS there.
There's a few options Linux supports on the command line. Ethernet would
be common. But also relies on a working TCP stack or minimal Ethernet
driver. Which is why it's good to have serial around. Simple interface
that only needs a simple hardware banging driver. :-)
In the meantime it looks like I've found where the little endian offsets
are coming from. So in a convoluted process to secure code inside a VM,
it compiles C to web assembly, which then transcodes it back into C
again affer being wrapped inside the RLBox routines to manage it, and
then finally compiles the result into a binary. The code that compiles
assembly is endian aware and looks like it codes the assembly stream to
be little endian when compiled on a big endian CPU. But it does in an
awkward way. The original code uses memcpy() even if it should be
sufficient and faster to just store scala data directly. But in big
endian it does a memcpy(), then copies to a temp array, byte swaps the
array and copies the array! Terrible! They just should have written a
reverse byte copy and avoid the mess. In any case since the assembly is
little endian the byte code is technically correct. The problem then is
in the RLBox wrapper as the native code generated is not byte swapping
in the final C generated. It's likely removing the swaps from web
compiler would actually fix it to work. Perhaps enough to work on big
endian. But because it complicates the process by using web assembly as
a middleman means such a solution wouldn't be technically correct.
Though the fault would end up in the RLBox transcoder not byte swapping
when reading scala data offsets it uses to generate C code.
--
My regards,
Damien Stewart.
Reply to: