qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: J. Mayer
Subject: Re: [Qemu-devel] RFC: cleanups in ELF loader
Date: Sun, 30 Sep 2007 04:28:57 +0200

On Sun, 2007-09-30 at 04:15 +0200, Edgar E. Iglesias wrote:
> 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?

It seems to me that you are right.
I'm still not able to run 64 bits user-mode programs on 32 bits hosts:
It seems to me that there are issues in mmap.c and signal.c. There still
are some issues to be fixed in syscall.c too or at least supicious code
generating compilation warnings which is to be checked.

Feel free to submit any patch that would help solve all those
confusions !

Regards.

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

[Prev in Thread] Current Thread [Next in Thread]