[Qemu-devel] Alpha update

[Qemu-devel] Alpha update

[Falk Hueffner]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi,

this patch will actually make "hello" run :) Some relocations are not
handled properly yet, though, and dynamically linked binaries don't
work. For the 4k page emulation, I grabbed mmap4k.c and pagemap.c from
em86. I've attached them as single files. The code looks somewhat
crufty though, maybe we should write something ourselves. By the way,
doesn't IA64 have the same problem? Also, it could probably be made
easier with a kernel patch...

-- 
	Falk


[-- Attachment #2: qemu-alpha-2003.04.30.patch.bz2 --]
[-- Type: application/octet-stream, Size: 3672 bytes --]

[-- Attachment #3: mmap4k.c.bz2 --]
[-- Type: application/octet-stream, Size: 4560 bytes --]

[-- Attachment #4: pagemap.c.bz2 --]
[-- Type: application/octet-stream, Size: 1248 bytes --]

Re: [Qemu-devel] Alpha update

[David S. Miller]

   From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
   Date: 30 Apr 2003 13:34:32 +0200
   
   I grabbed mmap4k.c and pagemap.c from em86. I've attached them as
   single files. The code looks somewhat crufty though, maybe we
   should write something ourselves. By the way, doesn't IA64 have the
   same problem? easier with a kernel patch...

Sparc has the same problem too.

It should be hacked simply to use get_pagesize().  Especially
because on some platforms, the page size is variable.

Re: [Qemu-devel] Alpha update

[David S. Miller]

   From: "David S. Miller" <davem@redhat.com>
   Date: Wed, 30 Apr 2003 03:48:30 -0700 (PDT)

      From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
      Date: 30 Apr 2003 13:34:32 +0200
      
      I grabbed mmap4k.c and pagemap.c from em86. I've attached them as
      single files. The code looks somewhat crufty though, maybe we
      should write something ourselves. By the way, doesn't IA64 have the
      same problem? easier with a kernel patch...
   
   Sparc has the same problem too.
   
For what it's worth, after some debugging I have sparc
successfully running the test/hello program using the
mmap4k code as well.

Re: [Qemu-devel] Alpha update

[Falk Hueffner]

"David S. Miller" <davem@redhat.com> writes:

> For what it's worth, after some debugging I have sparc successfully
> running the test/hello program using the mmap4k code as well.

Cool. Did you have change anything? How about dynamically linked
binaries, do they work?

-- 
	Falk

Re: [Qemu-devel] Alpha update

[David S. Miller]

   From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
   Date: 01 May 2003 21:27:04 +0200

   "David S. Miller" <davem@redhat.com> writes:
   
   > For what it's worth, after some debugging I have sparc successfully
   > running the test/hello program using the mmap4k code as well.
   
   Cool. Did you have change anything? How about dynamically linked
   binaries, do they work?

The only other thing I tested was test-i386 and most of that passed.

There are some problems I'm trying to deal with now with respect to
register windows, it just requires some brainstorming.

If you could clean up the mmap4k code (in particular to make it
determine the host page size dynamically using get_pagesize()) that
would help me concentrate on sparc specific issues.

Re: [Qemu-devel] Alpha update

[fabrice.bellard]

Quoting "David S. Miller" <davem@redhat.com>:

> There are some problems I'm trying to deal with now with respect to
> register windows, it just requires some brainstorming.

I've seen that gcc for Sparc has an option to generate "flat" code not using 
register windows. Have you considered using that ?

Fabrice.

Re: [Qemu-devel] Alpha update

[David S. Miller]

   From: fabrice.bellard@free.fr
   Date: Sat, 03 May 2003 19:29:26 +0200 (CEST)

   Quoting "David S. Miller" <davem@redhat.com>:
   
   > There are some problems I'm trying to deal with now with respect to
   > register windows, it just requires some brainstorming.
   
   I've seen that gcc for Sparc has an option to generate "flat" code
   not using register windows. Have you considered using that ?

I already played with this :-)

It's not usable because due to a bug in gcc when you
use -mflat it doesn't honor -fno-delayed-branch.

I have to use -fno-delayed-branch so that the instructions emitted for
the op-i386.o routines don't have pieces moved into the delay slot of
the sparc return instruction.

I have test-i386 fully passing except for 3 float tests at this
point.  Once I resolve that I'll start playing with using shared
libraries and things like that.

[Qemu-devel] Alpha update

[Falk Hueffner]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Hi,

this patch does gp and __op_param handling correctly, following a
suggestion from Richard Henderson. Also adds support for PC-relative
jumps. I believe the translation engine itself is now complete. And I
added an Alpha disassembler lifted from binutils.

However, there are still problems with the ELF loader. It seems like
some binaries want a mmaping at an offset that is not divisible by the
page size:

./qemu -d /usr/local/qemu-i386/bin/ls-i386
[...]
mmap4k(start = 0x8052000, length = 592, prot = 0x3 (rw),
       flags = 0x2102 (MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE),
       fd = 4, offset = 39040)

39040 % 4096 == 2176

Alpha Linux 2.5.69 doesn't seem to handle unaligned offsets. Do other
architecures? Or earlier versions? The em86 code doesn't seem to care
about this at all. The only thing to handle this I can think of is to
mmap anonymously and use read() to fill in the data... or am I missing
something?

-- 
	Falk

[-- Attachment #2: qemu-alpha-2003.05.11.patch.bz2 --]
[-- Type: application/octet-stream, Size: 16416 bytes --]

Re: [Qemu-devel] Alpha update

[Fabrice Bellard]

Falk Hueffner wrote:
 > Hi,
 >
 > this patch does gp and __op_param handling correctly, following a
 > suggestion from Richard Henderson. Also adds support for PC-relative
 > jumps. I believe the translation engine itself is now complete. And I
 > added an Alpha disassembler lifted from binutils.
 >
 > However, there are still problems with the ELF loader. It seems like
 > some binaries want a mmaping at an offset that is not divisible by the
 > page size:
 >
 > ./qemu -d /usr/local/qemu-i386/bin/ls-i386
 > [...]
 > mmap4k(start = 0x8052000, length = 592, prot = 0x3 (rw),
 >        flags = 0x2102 (MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE),
 >        fd = 4, offset = 39040)
 >
 > 39040 % 4096 == 2176
 >
 > Alpha Linux 2.5.69 doesn't seem to handle unaligned offsets. Do other
 > architecures? Or earlier versions? The em86 code doesn't seem to care
 > about this at all. The only thing to handle this I can think of is to
 > mmap anonymously and use read() to fill in the data... or am I missing
 > something?

Hi,

I commited your latest patches for Alpha.

For the mmap problem, I will integrate something like mmap4k, but I need
to make some patches in it so that the 'pagemap' stuff can be used in
the CPU emulator to handle self-modifying code and explicit translation
cache invalidation.

BTW, it was mentionned that variable host page size support was
necessary. Would a configure time probe be OK or should it be
dynamically probed ?

Fabrice.

Re: [Qemu-devel] Alpha update

[David S. Miller]

   From: Fabrice Bellard <fabrice.bellard@free.fr>
   Date: Sun, 11 May 2003 15:10:23 +0200
   
   BTW, it was mentionned that variable host page size support was
   necessary. Would a configure time probe be OK or should it be
   dynamically probed ?

It must be dynamically probed using get_pagesize().

Re: [Qemu-devel] Alpha update

[Fabrice Bellard]

Fabrice Bellard wrote:
>  > However, there are still problems with the ELF loader. It seems like
>  > some binaries want a mmaping at an offset that is not divisible by the
>  > page size:
>  >
>  > ./qemu -d /usr/local/qemu-i386/bin/ls-i386
>  > [...]
>  > mmap4k(start = 0x8052000, length = 592, prot = 0x3 (rw),
>  >        flags = 0x2102 (MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE),
>  >        fd = 4, offset = 39040)
>  >
>  > 39040 % 4096 == 2176
>  >
>  > Alpha Linux 2.5.69 doesn't seem to handle unaligned offsets. Do other
>  > architecures? Or earlier versions? The em86 code doesn't seem to care
>  > about this at all. The only thing to handle this I can think of is to
>  > mmap anonymously and use read() to fill in the data... or am I missing
>  > something?

I don't see how it is possible in this particular case: the ELF file is 
built to be mapped directly in memory so it is a bug in the ELF loader 
logic.

Note: The 2.4.x kernel also refuses unaligned offsets on i386.

Fabrice.