[OpenBIOS] [PATCH] RFC: Increase dictionary size on SPARC64

[Mark Cave-Ayland]

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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs