From: "Nardmann, Heiko" <heiko.nardmann@secunet.com>
To: qemu-devel@nongnu.org, Juergen Keil <jk@tools.de>
Subject: Re: [Qemu-devel] Building qemu on UltraSparc
Date: Tue, 24 May 2005 17:14:24 +0200 [thread overview]
Message-ID: <200505241714.40595.heiko.nardmann@secunet.com> (raw)
In-Reply-To: <200505241220.j4OCKkXq022785@imap3.tools.intra>
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]
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 #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-05-24 15:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-24 12:20 [Qemu-devel] Building qemu on UltraSparc Juergen Keil
2005-05-24 15:14 ` Nardmann, Heiko [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-05-23 8:38 Juergen Keil
2005-05-24 10:58 ` Nardmann, Heiko
2005-05-21 17:32 Jérôme Warnier
2005-05-21 23:26 ` Herbert Poetzl
2005-05-22 0:13 ` Jérôme Warnier
2005-09-04 1:13 ` Jérôme Warnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200505241714.40595.heiko.nardmann@secunet.com \
--to=heiko.nardmann@secunet.com \
--cc=jk@tools.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.