On 10/11/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > Fabrice Bellard wrote: > > Thiemo Seufer wrote: > >> Fabrice Bellard wrote: > >>> J. Mayer wrote: > >>>> Following the patches done for elfload32, it appeared to me that there > >>>> were still problems that would prevent 32 bits executables to run on 64 > >>>> bits target in linux user mode emulation. > >>>> [...] > >>> Are you sure it is a good idea to try to add 32 bit executable support to > >>> a 64 bit target ? In the end you will need to write a 64 bit to 32 bit > >>> linux syscall converter which would mean duplicating all the linux-user > >>> code of the corresponding 32 bit target (think of ioctls with strutures, > >>> signals frames, etc...). > >> I would think this feature will be limited to platforms which can handle > >> 32bit and 64bit binaries with a single personality. > > > > I am not sure it is a common case ! > > > > However, I suggest to emulate a 32 bit user linux system with a 64 bit > > guest CPU running in 32 bit compatibily mode. It would be useful to test 64 > > bit CPUs in 32 bit compatibility mode. The only required modification in > > linux user is to rename target_ulong so that it can have a different size > > of the CPU word default size. > > Doesn't work for MIPS64, since it doesn't quite have a compatibility mode > in the traditional sense. It needs to retain 64bit register width when > running N32 ABI binaries. (Thus the somewhat odd overrides I added for > the preliminary N32 support.)
CPU registers (and storage for full width registers) would still be 64 bits. The ABI uses of target_ulong need to be changed to, for example abi_ulong so that the size can be changed. Sparc64 does not have a compatibility mode either (except for address masking), it can run Sparc32 binaries because of the cleverly designed instruction set. Ops use full 64 bits of a register, but there are two sets of CPU flags, 32 and 64 bits.
