> On Thu, 23 Oct 2003, Ian Fry wrote:
> 
> > On Thu, Oct 23, 2003 at 10:13:24AM +0100, Chris Gilbert wrote:
> > > Just browsing over the pmap code, and noticed this comment:
> > >  *     o If the vector_page is at 0x00000000 instead of 0xffff0000, then
> > >  *       MP systems will lose big-time because of the MMU domain hack.
> > >  *       The only way this can be solved (apart from moving the vector
> > >  *       page to 0xffff0000) is to reserve the first 1MB of user address
> > >  *       space for kernel use only. This would require re-linking all
> > >  *       applications so that the text section starts above this 1MB
> > >  *       boundary.
> > >
> > > I know that currently we don't do MP on arm, there was some work done to
> > > support hydra MP, and long term I believe that arch v6 chips will
> > > support SMP (although I'd guess they can remap the vector table)
> >
> > If this is done, what happens to old binaries linked at the old address?
> > (e.g. 1.6.x binaries running on 2.x under emulation)
> 
> On systems that don't need the bottom megabyte clear (i.e. uniprocessors
> and SMPs with high vectors), they'd carry on working.  On SMPs with low
> vectors, I expect old binaries would generate ENOEXEC.
> 


Is there any reason why arm26 couldn't put the stack below 1MB?

That would allow the space to be used in a way that wouldn't affect the 
content of the executable and arm32 could continue to put the stack in its 
existing position (in fact, it could chose, depending on the stack size 
limit).

R.