qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] IRIX host


From: Paul Brook
Subject: Re: [Qemu-devel] IRIX host
Date: Fri, 10 Sep 2004 17:33:15 +0100
User-agent: KMail/1.7

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




reply via email to

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