On Sun, Sep 30, 2007 at 03:39:15AM +0200, 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. > I tried to fix this. I also noticed that the image infos start_data > field was not computed as the Linux kernel does. As the ARM and the > Alpha targets use this information to initialize the program state > before execution, it seems a good idea (to me !) to fix it. > As this patch can have an impact on all user-mode emulated targets, I'd > be glad to have some comments about it to figure if it seems safe to be > commited or if some rework will be needed. > > Thanks by advance.
Hello, I'm new but FWIW your changes look fine to me. Recently while trying out the sparc64 user emulation on a 32bit host I found another similar cause of confusion. I'm not sure if it's a problem in reality but I thought I'd mention it for the record. target_mmap currently returns a long, but most of it's callers seem to assign the returned address to a target_ulong (elfload.c) or to a target_long (syscall.c). On my particular build (64bit target and 32bit host) the address returned by the host mmap was sign-extended when assigned to a target_ulong. For example, if the host returns 0x80000000, the 64bit address ended up beeing 0xffffffff80000000. I assumed this was intentional to simplify the catching of the -1 failure code. Not sure if it's a problem, but it confused me at least. I would have expected target_mmap to return a target_long, and that it internally would conditionally sign extend the hosts mmap return value only if it was -1. This would make it easy for the callers to check for errors while preserving valid addresses through zero-extension. Does this make any sense? Best regards -- Edgar E. Iglesias Axis Communications AB