Re: More toolchain issues

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Sun, 27 Sep 2009 15:47:51 -0600 (MDT)
"Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost> wrote:

>    This is likely where malloc() allocated memory - outside the area
> where the process data is normally expected to be.
> 
> > 08500000   1024K read/write          [ anon ]
> > 08600000   1024K read/write          [ anon ]
> ...
> > 0BE00000   1024K read/write          [ anon ]
> > 0BF00000   1024K read/write          [ anon ]
> 
>    And we have now allocated all the remaining user address space and
> hit the stack area - well less than the 128MB memory limit.
> 
> > 0C000000  30720K                     [ stack ]

Oh. There is indeed less than 64MB of space in between...


> > 0DE00000   1920K read/write          [ stack ]
> > 0DFE0000    128K read/write          [ stack ]
> > total    67736K
> 
>    Most ports probably don't see this behaviour because they are
> configured with a much larger user address space and most likely have
> plenty of space between the shared libraries and stack to allocate
> memory.

I just checked that all of these ports have a possibility for SUNOS_COMPAT,
so this should be no problem.


>    That limited user address space configuration is apparently due to 
> trying to compatible with SunOS.  I'm not sure if it's really
> necessary to have the USRSTACK at 0x0e000000 to remain compatible,
> and I think I may have run an old sunos mosaic binary I have with an
> expanded user address space (but I can't remember for sure).

I don't have access to any SunOS binaries. Can anybody verify that?


>  I think
> the amiga could easily move USRSTACK to 0x1c000000 [any larger will
> run into a pmap limitiation that can allow user programs to crash a
> 680[46]0 system].

Ok. I'm all for it! This gives us an adress aspace of more than 256MB,
which should be enough for 68k Amigas.

AFAICS mac68k still offers SunOS-compatibility, although their USRSTACK
is not at 0x0e000000.


-- 
Frank Wille