linux-mips
[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: Richard Sandiford <rsandifo@redhat.com>
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Date: Mon, 23 May 2005 19:32:00 +0200 (MET DST)
Cc: linux-mips@linux-mips.org
In-reply-to: <8764x926wq.fsf@firetop.home>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
> I'm talking about the %hi() and %lo() relocation _operators_,
> not the ELF relocations themselves.  The ELF spec has nothing
> to say about the syntax of assembler relocation operators.

OK, right :)

> What do you mean?  I'm talking about reordering the relocations in
> the .rel.foo section, not reordering the code.  I.e. if you have:
> 
>     .text
>     ...
>     addiu $4,$4,%lo(foo)
>     ...
>     lui $4,%hi(foo)
> 
> the assembler is expected to output the R_MIPS_HI16 .rel.text entry
> for the lui before the R_MIPS_LO16 entry for the addiu.

If you have something like that:

        .text
        ...
loop_label:
        lui $4, %hi(foo)
        addiu $4, $4, %lo(foo)
        ...
        jmp loop_label
        ...

the compiler might be smart and change it into:

        .text
        ...
        lui $4, %hi(foo)
loop_label:
        addiu $4, $4, %lo(foo)
        ...
        lui $4, %hi(foo)
        jmp loop_label
        ...

for instance, to put the lui into branch delay slot (quite a smart
decision, this one). However now %hi and %lo are unpaired. What should the
tool do?

Cheers,

Stanislaw



<Prev in Thread] Current Thread [Next in Thread>