linux-mips
[Top] [All Lists]

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

To: kumba@gentoo.org
Subject: Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 29 Mar 2007 23:53:33 +0900 (JST)
Cc: linux-mips@linux-mips.org, ths@networkno.de, ralf@linux-mips.org
In-reply-to: <460B1B64.1040401@gentoo.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <460A6CED.1070308@gentoo.org> <20070329.002453.18311528.anemo@mba.ocn.ne.jp> <460B1B64.1040401@gentoo.org>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 28 Mar 2007 21:50:28 -0400, Kumba <kumba@gentoo.org> wrote:
> Doing some tests, I found out that by commenting out one or more of the 
> daddui/dsll instructions for IP32 produced a kernel that still booted, but 
> hung 
> at running init/freeing kernel memory.  Using the single lui booted once, but 
> I 
> suspect that was my fault on not doing something proper, cause the next time 
> around, it didn't boot at all.  I tested this all on a real console, versus 
> serial, case there was an early panic or something.  But I see nothing to 
> indicate why IP32 dislikes the lui->ld sequence versus the 
> lui->daddui->dsll->etc->ld sequence.

Hmm... really strange.

This is OK:
                lui     k1, %highest(kernelsp)
                daddiu  k1, %higher(kernelsp)
                dsll    k1, k1, 16
                daddiu  k1, %hi(kernelsp)
                dsll    k1, k1, 16

This is NG:
                lui     k1, %hi(kernelsp)

So, could you try this one?

                nop
                nop
                nop
                nop
                lui     k1, %hi(kernelsp)

If it booted, the problem should be in something irrelevant place.
I.e. this optimization just triggers other bug by code/data movement.

---
Atsushi Nemoto

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