qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Building qemu on UltraSparc


From: Nardmann, Heiko
Subject: Re: [Qemu-devel] Building qemu on UltraSparc
Date: Tue, 24 May 2005 17:14:24 +0200
User-agent: KMail/1.8

On Dienstag 24 Mai 2005 14:20, Juergen Keil wrote:
[snip]
> > ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o):
> > symbol __op_gen_label1: value 0x34c21f does not fit
> > ...
> > ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o):
> > symbol __op_gen_label1: value 0x34a0d3 does not fit
> >
> > collect2: ld returned 1 exit status
> >
> > Any idea what is happening here?
>
> Part of the problem is my GOTO_LABEL_PARAM macro for sparc, in
> dyngen-exec.h:
>
>     #define GOTO_LABEL_PARAM(n) asm volatile ("ba "
> ASM_NAME(__op_gen_label) #n ";nop")
>
>
> We have 22 bits in the branch instruction to encode a signed 32-bit word
> offset, relative to the current PC. The target address is always a
> multiple of 4, so the offset encoded in the branch instruction is an
> offset measured in 32-bit words.
>
>
> The sparc branch instructions cannot jump forward / backward more than
> 8 mbytes (2^21 * 4 = 8mbyte).
>
>
> What appears to be happening on your system is that the opcode
> templates from the code section for "target-i386/op.c" (these contain
> the "ba" branch instruction from the GOTO_LABEL_PARAM macro) jump to an
> integer variable that is allocated somewhere in the data or bss section
> (the "int __op_gen_label1" variable defined in dyngen.h), and the code
> & data section on your system are more than 8 mbytes apart.
>
>
> Apparently I had luck upto now, because on my solaris 10 sparc box there
> have been no such issues with R_SPARC_WDISP22 relocation errors.
>
> > ld: fatal: relocation error: R_SPARC_WDISP22: file libqemu.a(op.o):
> > symbol __op_gen_label1: value 0x34c21f does not fit
>
>   --> 0x34c21f * 4 = 13830268 = 13.8 mbytes
>
>
> I guess this can be fixed by moving the branch target "__op_gen_label1"
> from the data section to the code section.  A "size" on my sparc qemu
> binary reports a total code size of ~ 1 mbyte, so that there should be
> no issues with R_SPARC_WDISP22 overflows when both the branch instruction
> and the branch target are both in the code (.text) section.
>
[snip]

Although I do not fully understand your explanation ... it works now with your 
patch.

Thanks!

Does this stuff go into CVS?

-- 
Heiko Nardmann (Dipl.-Ing. Technische Informatik)
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax  : +49 271 48950-50

Attachment: pgpXb51LmZFaI.pgp
Description: PGP signature


reply via email to

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