[Top][All Lists]
[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