qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] s390 host support


From: Bastian Blank
Subject: Re: [Qemu-devel] s390 host support
Date: Tue, 13 Nov 2007 14:00:52 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, Nov 12, 2007 at 06:14:43PM +0100, Ulrich Hecht wrote:
> On Saturday 10 November 2007, Bastian Blank wrote:
> > Thimo Seufer asked me to check if the s390 host supports works at all.
> > It did not even build, dyngen failed.
> A 31-bit build of the CVS code works fine for me.

Please describe the environment you work in, including compiler versions
and patchsets.

For me it does not work with gcc 3.4, 4.2, 4.3 snapshot from september
with binutils 2.18 from Debian unstable. The gcc includes patches for
multilib support. The testenvironment is a z900 aka 2064.

> A 31-bit build of the CVS code works fine for me. (At least if I add the 
> br %rANY fix that is also in your patch and the jcc patch that Thiemo 
> has not committed yet.)

The jcc fix looks like a workaround for an undescribed problem. Please
describe this. Hmm, the comments say "for unknown reasons".

> A 31-bit build using your patch works as well, but it also needs the jcc 
> patch.

Nope, all my tests worked fine so long.

>        The only reason it needs to be compiled with -march=z900 is the 
> use of larl in the inline assembly code,

No. -march=z900 changes the generated code.

> > I digged into the problem and 
> > found the following:
> > gcc for s390 generates a data table after each function if necessary
> > instead of immediate loads.
> It actually generates it inline, doing something like
> op_something:
> bras %r13, 8
> .long <some data>
> ...

If you use -O0 it sometimes generates this code and the data table in
versions up to 4.2. Using 4.3, I never saw this.

> > - Support R_390_PC32DBL relocation, including relocations into
> > sections.
> Again, my GCC only generates this relocation when compiling 64-bit code. 

The GCC does not generate any relocation. Relocations are emited by the
assembler. And binutils 2.18 emits this.

> With your patch and some obvious fixes (ELFCLASS64, GETPC, 
> $hostlongbits)) it builds as 64-bit, but it segfaults in the first 
> translation block.

I did'n say it will work in 64bit mode.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
                -- Scotty




reply via email to

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