Date: Tue, 06 Jan 2009 10:39:44 -0800 (PST)
Message-Id: <20090106.103944.99651976.davem@davemloft.net>
To: sam@ravnborg.org
Cc: viro@ZenIV.linux.org.uk, jbeulich@novell.com, mingo@elte.hu,
       rostedt@goodmis.org, srostedt@redhat.com, linux-kernel@vger.kernel.org,
       sparclinux@vger.kernel.org
Subject: Re: ftrace breaks sparc64 build
From: David Miller <davem@davemloft.net>
In-Reply-To: <20090106133442.GA14780@uranus.ravnborg.org>
References: <49631BF0.76E4.0078.0@novell.com>
	<20090106113543.GS28946@ZenIV.linux.org.uk>
	<20090106133442.GA14780@uranus.ravnborg.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 854
Lines: 20

From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 6 Jan 2009 14:34:42 +0100

> But I never managed to really understand what the btfixup thing is all
> about and has then been sidetracked by funnier stuff.

It's recording relocations that get fixed up at boot time.

The way it works is that each btfixup emits a reference to a symbol
that will be unresolved.

The btfixup tool under arch/sparc/boot/ scans the unlinked kernel
image, generates dummy symbol definitions into a foo.s file so that
the kernel can be linked, and builds the btfixup tables so the kernel
can patch up these relocations at boot time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/