Boxed value caching, for memory saving can be done with linked lists
valueOf lookup would be very slow. It might be best to
not cache at all.
I need a faster huffman lookup code, since that is quite slowing down my build much (since I need to decompress the ZIP files). If I make the huffman lookup fast then it should compile much faster. I devised my own seemingly good speed huffman lookup using remaining bits and such, on my markerboard. With a random huffman tree that I setup, each resulting value ends up being in a single index.
So I need to figure out what is wrong with my ELF and why it says "Invalid Argument".
Unless, a program header of zero is considered invalid, but other binaries use the zero program header. Unless I absolutely need a data section.
However, removing the data section of a binary makes it still work (although in the practice binary no text is printed).
Looks like QEMU fails in
load_elf_interp. However my binary does not have
an interpreter because it is static. Also looks like the ELF is completely
corrupted too. But that structure is not initialized. So either
elf_check_ident fails or
So now I built a debug version of QEMU.
Looks like it fails because the host page alignment is not correct, right now the alignment is just zero so perhaps if it were made to be 4K.
I am actually going to need a better ELF writing class, with perhaps a builder since there can be a large number of differences between different systems which use ELF. I suppose the best thing to do would be to make it object oriented so I can declare what I need.
Looks like the end address
Entry point address: 0x444cd0 is
not valid. And I hope it will work now.
Now it says invalid argument.
Appears that QEMU (and I suppose) Linux are trying to directly memory map the ELF binary. Since the offset in the file is not meeting the target page mask, it fails to load properly. However in the hello binaries there are:
[ 3] .text PROGBITS 00400018 001018 000020 00 AX 0 0 4 [ 2] .text PROGBITS 004000b0 0000b0 000020 00 AX 0 0 16
In the second case
0xb0 can be divided by 16. Also appears the target page
bits in QEMU MIPS is 12-bits.
Actualy sections are pointless. The hello worlds have:
LOAD 0x001000 0x00400000 0x00400000 0x00038 0x00038 R E 0x1000 LOAD 0x000000 0x00400000 0x00400000 0x000d0 0x000d0 R E 0x10000
While mine has:
LOAD 0x0000d8 0x00400000 0x00000000 0x44cd4 0x44cd4 R E 0x1000
So this means that the offset in the file has to match the alignment. So in short I need a new and better ELF writer. The ELF writer has to be rewritten anyway to be much better, because currently this is not going to work. SquirrelJME is also a bit large at around 275KiB without any code. I can see it becoming about 1MiB with everything. This is just an initial target however. Eventually a new output could be generated which likely uses less size. But also consider that the extra space is consumed by resources. So if entries were to be deflated the binaries would be much smaller too. In the end, I would deflate entries anyway.
ExecutableOutput needs to lose the linking, where it completely
becomes implementation dependent on what is done.