From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] IRIX host
Date: Fri, 10 Sep 2004 17:33:15 +0100 [thread overview]
Message-ID: <200409101733.15506.paul@codesourcery.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0409101735530.32451@wgmdd8.biozentrum.uni-wuerzburg.de>
On Friday 10 September 2004 17:15, Johannes Schindelin wrote:
> Hi,
>
> I played around a little bit with dyngen in order to understand it. For my
> own pleasure I tried to compile it on IRIX (HOST_MIPS).
>
> For your pleasure I write down what I learnt so far:
>
> I soon found out that gcc produces RELOCA objects, not RELOC: I added
> HOST_MIPS specific code in the places where an "unsupported cpu" error
> occurred - 3 places in total - , and inserted a printf to show which
> relocations were found. With RELOC, there were none, with RELOCA, there
> were some. I know I am lazy, probably I would have found out by RTFM.
>
> Also, it was quite easy to do the return finding stuff. I used "objdump
> --disassemble-all i386-softmmu/op.o" to find out what the code looks like,
> learning a little MIPS assembly on the way. Seems that "jr ra" is the
> return statement, and "nop" are used to pad up to align to 8-byte
> boundaries.
IIRC MIPS has "branch delay slots", so these may not just be padding.
> But now comes the biggest task: the relocations. In order to provide the
> dynamically generated assembler code with the right parameters, C
> functions for each assembler instruction are compiled into op.o, where a
> placeholder is passed for each possible parameter. These parameters -
> identified by their placeholders - will be filled in by the dynamic
> compiler, dyngen_code(). This compiler is written by dyngen in the form of
> a header file, op.h.
>
> Unfortunately this does not seem to work on IRIX as I expected it would:
> If I understand correctly, and you want to reference a parameter (say
> __op_param1), then the address of __op_param1 gets stored somewhere in a
> global table, and the 16-bit offset in that table is actually stored in
> the code.
This sounds like you're generating PIC code. A few options spring to mind:
- Generate non-pic code. I don't know if MIPS/IRIX has a non-pic option.
- Change the definition of __op_param1 so it generates a more convenient
relocation.
- Do something clever with the GOT-indirect relocation. eg. turn it into a
pc-relative reference to a constant pool.
Paul
next prev parent reply other threads:[~2004-09-10 16:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 22:14 [Qemu-devel] [patch] incorrect VGA initialization, can provide image Piotr Krysik
2004-09-10 10:20 ` Johannes Schindelin
2004-09-10 12:26 ` Piotr Krysik
2004-09-10 13:17 ` Fabrice Bellard
2004-09-10 16:15 ` [Qemu-devel] IRIX host Johannes Schindelin
2004-09-10 16:33 ` Paul Brook [this message]
2004-09-10 18:34 ` [Qemu-devel] [patch] incorrect VGA initialization, can provide image Piotr Krysik
2004-09-13 21:29 ` Fabrice Bellard
2004-10-11 7:40 ` Piotr Krysik
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=200409101733.15506.paul@codesourcery.com \
--to=paul@codesourcery.com \
--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.