qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] IRIX host


From: Johannes Schindelin
Subject: [Qemu-devel] IRIX host
Date: Fri, 10 Sep 2004 18:15:11 +0200 (CEST)

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.

 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.

Is there somebody with a clue of MIPS assembly who can either affirm that
or correct me?

And if I am correct, how would you go about patching those relocations?
You certainly cannot modify address in the global table everytime you want
to use that (guest) assembly instruction. BTW, I did not succeed in
convincing my gcc (v3.0.4) to not use the global table.

Ciao,
Dscho

P.S.: When I understand completely what is going on, I will write it up
and polish it so that everybuddy is able to understand it.




reply via email to

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