Re: [Qemu-devel] RFC: cleanups in ELF loader

[Edgar E. Iglesias]

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