On Sat, 25 Nov 2000, Richard Earnshaw wrote:

> I'd suggest -mapcs-26+32 ;-)  (if it turns out that we really need 
> anything at all.

If people don't mind -mapcs-32 turning on dynamic processor-mode checking
(which is rare and cheap anyway), then we can get away without.  I suspect
this is the way to go.

> > interesting.  MASK_RETURN_ADDR needs to be an rtx that is used to mask off
> > the PSR bits from return addresses, and hence needs to generate code to
> > check the processor mode at runtime.  The recommeded way to do this is:
> > 
> >         TEQ     R0, R0          ; sets Z (can be omitted if not in User mode)
> >         TEQ     PC, PC          ; EQ if in a 32-bit mode, NE if 26-bit
> 
> I'm missing something here.  What does the first instruction give us?

It ensures that at least one flag is set.  Otherwise, if we're in USR26
mode, NZCV are clear and interrupts are enabled, the second test will give
EQ erroneously.

> As for making this dynamic, that isn't too hard, we just need to make 
> MASK_RETURN_ADDR into a sequence of instructions that returns a value, 
> rather than a static constant as it currently is.  This macro is only used 
> when throwing exceptions, so it isn't a major overhead.

Yes, in theory it's quite easy.  In pactice, it needs someone who knows
how the internals of GCC work.

> > A final thing that needs to be considered is that arm26 requires sections
> > to be aligned on 32k boundaries, so the linker will have to be set up to
> > arrange this.
> 
> This will of course have a cost for arm32 people in that it will make 
> their binaries bigger.

Hmm, yes.  This could be a problem.  Binaries that waste 32k at the start
aren't nice.  It should always be possible to leave a hole in the file
there, but that makes copying them around painful.  An alternative would
be to work out how to do QMAGIC (is that the one?  Where the file header
is in the text segment) in ELF.

> There may also have to be some work done in the 
> kernel to force it to load such images on well-aligned pages,

I don't think this will need any kernel changes -- the ELF loader is quite
good at getting things right.

> A trick that was done in the RISX iX world was to merge the last (partial) 
> text page with the first data page, mapping the entire page read-write; 
> this meant that for many small programs, the image could be kept to just 
> 32K.  I've no idea whether we can (or already do) play a similar trick on 
> NetBSD.

Mostly by accident, the current arm26 linker script does this.  I think it
actually maps the entire text segment read/write at the moment, but COW
should make that fairly cheap.  It'd probably be better to move this
functionality into the loader, though.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>