On Wed, 4 Sep 2002, Ralf Baechle wrote:
> > It would be nice if we could keep a single set of syscalls for both (n)64
> > and n32. The address crop for n32 may be handled the Alpha way. I will
> > investigate the topic soon.
>
> Can you describe how this is handled on the Alpha?
I'm referring mostly to OSF/1 here as it was first to implement it.
Linux followed it in the sense it is able to execute OSF/1 binaries marked
as "32-bit", but native ELF binaries used to be fully 64-bit always. I
think by a popular demand GNU binutils are now able to create "cropped"
Alpha/Linux ELF binaries as well, but this is unverified for sure. The
implementation is two-fold.
First, the static linker (if given the "-taso" option) maps an executable
into the low 31-bit address space (coincidentally, this will probably be
suitable for MIPS as well) and sets a special flag in the executable (it
does it in a weird place, but this is ECOFF and we have suitable flags in
the ELF header already).
Second, seeing the "31-bit" flag set, the kernel returns any maps
requested within the low 31-bit address space. This way both shared
libraries (which thus need not be special, i.e. may be regular 64-bit
ones) and areas allocated by mmap() are addressable by the executable.
To summarize, nothing much complicated.
> The primary problem is the differnet calling sequence for o32 and N64.
But we handle that already.
> As it looks we'll be able to use either the o32 function or the native
> syscall to implement all of the necessary N32 syscalls.
The (n)64 versions seem suitable and the o32 ones do not as n32 only
crops addresses to 32-bit -- data may still be 64-bit (e.g. file position
pointers).
> The question is if we want to reserve another 1000 entries in our already
> huge syscall table for N32 or if we got a better solution ...
Aaarrgh, no more entries, please...
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|