Artyom Tarasenko wrote:
One possible problem may be that we overrun the 32 bit address space, because there is only 3M available: 0xffd00000 to 0xffffffff.
Oh. I guess that's the amount stored in totmap[0].num_bytes in sparc32/lib.c? Then obp_dumb_memalloc really has too few space for loading Solaris kernel. Maybe because the memory is not freed.
That's only on Sparc32, but memory could be tight there too, the layout is the same.
There should be quite a few tricks to reduce memory consumption: compile with -Os, remove or make unused code conditional, optimize mixed C/Forth constructs like fword("xx") etc.
Right. This also explains why the code compiled with -o0 or debugging enabled doesn't go as far as the optimized code when using Solaris 2.5.1. Basically the memory corruption bug I reported was at least partly produced by the debugging method itself.
Is this correct? A build of SPARC32 OpenBIOS here with -O0 -g comes to about 560K which is well within the 3M limit.
I think from one of the logs you posted earlier that SPARC32 was invoking the a.out loader. From libopenbios/aout_load.c you can see that any a.out executables are loaded at a fixed address of 0x4000 which seems a little strange given that the start address is given in the executable header.
Perhaps it's worth changing start to N_TXTADDR(ehdr) as the comment in line 117 suggests (or checking to see if it's set to 0x4000 or not) because if the SPARC32 loader is like the SPARC64 loaders I've been looking at, they assume they load at a particular address (the header address) and thus set up their own MMU mappings accordingly. Hence if the executable is being loaded at the wrong address, the physical <-> virtual address mappings for these locations will be undefined which will cause unpredictable results.
This also means that you don't need to worry about any loaded binary program image having to fit within 3M because they are loaded directly into their memory target location, and not into the upper memory location first.
ATB,
Mark.