J. Mayer wrote: > On Sun, 2007-09-30 at 17:09 +0200, J. Mayer wrote: > > On Sun, 2007-09-30 at 14:38 +0100, Thiemo Seufer wrote: > > > J. Mayer wrote: > > > > Following what I've done in the syscalls emulation routines, it appeared > > > > to me that there seems to be a lot of confusions between host and target > > > > long in the ELF loader. > > > > > > But the ELF fields are tied to the ELFCLASS of the supported ABI, not to > > > the register width of the machine emulation. If anything they should > > > become the ELF types. > > > > > > (Your approach will e.g. break down for MIPS N32, where "long" is smaller > > > thant the register width, and the ABI uses ELFCLASS32.) > > > > OK, I will try to rework this. > > I did check in the linux kernel and it appears that all variables I > changed from unsigned long to target_ulong seem to be unsigned long in the > kernel. This looks fine for me as they are addresses in the process virtual > address space, > so they should fit in a target_ulong, whatever the target registers size > could be.
As long as eventual sign extensions are done properly this is ok. (Some places in the kernel have casts to elf_greg_t for that purpose.) > What seems bugged to me (but I did not make any change in that part) is > the auxiliary vectors generation. This seems to me to be the only place > where Linux explicitelly uses elf_addr_t so Qemu should do the same. > Then, it seems that my patch is not so bad and should not break anything > but is not complete as it does not fix the auxiliary vectors. > > Do you agree with this, or did I miss something else ? The kernel loader (fs/binfmt_elf.c) is somewhat geared towards single ABI architectures. PowerPC, MIPS, SPARC etc. have all their own kludge (in arch/$ARCH/kernel/binfmt_elf*.c) to redefine some essential bits and then #include fs/binfmt_elf.c. The whole thing looks a bit scary, I'm not sure we should import it in Qemu. OTOH it is generally a good idea to stay in sync with the kernel implementation. Thiemo
