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: Edgar E. Iglesias
Subject: Re: [Qemu-devel] RFC: cleanups in ELF loader
Date: Sun, 30 Sep 2007 04:38:06 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

On Sun, Sep 30, 2007 at 04:28:57AM +0200, J. Mayer wrote:
> 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 !

Thanks, I'll try get sometime for looking at it this week.

Best regards
-- 
Edgar E. Iglesias
Axis Communications AB




reply via email to

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