Presently there is very little standing in the way of using an SH-4
toolchain for building an SH-2 kernel, and vice versa. Binutils itself
has no limitations whatsoever and supports explicit ISA hinting, which
we already use with varying degrees of success today.
This leaves GCC as the odd one out, due to a rather dubious policy
decision by the GCC folks to not include all of the CPU family variants
in the default list of multilib targets in GCC4. Despite best efforts to
the contrary, libgcc itself already contains awareness of the various CPU
types and remains generally usable, allowing it to safely be referenced
even on a mismatched target (and indeed, explicit ISA tuning by binutils
keeps us honest in terms of ensuring that we do not link incompatible
objects in).
In order to support this, a couple of changes had to be made. Firstly,
the introduction of MAYBE_DECLARE_EXPORT(), which provides a __weak
extern reference for libgcc resident routines when finer-grained
-m<cpu-family> based tuning is not supported by the toolchain. This
fixes up the __sdivsi3_i4i and __udivsi3_i4i references when dealing
with SH-2 kernels linked with an SH-4 libgcc. Secondly, in case where we
are unable to find a suitable match for CPU family tuning but still
have a toolchain that defaults to FP instruction generation, a suitable
nofpu target must be selected. This is accomplished by selecting the
first nofpu multilib target supported by the toolchain, which is
also necessary for selecting the proper libgcc to link against.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This adds support for ftrace to SH. This only includes CONFIG_FTRACE,
and does not handle dynamic ftrace presently.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
rsk7203_defconfig fails to build with the following error:
<-- snip -->
...
LD .tmp_vmlinux1
arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to `__udivsi3_i4i'
arch/sh/kernel/built-in.o:(__ksymtab+0xc8): undefined reference to `__sdivsi3_i4i'
make[1]: *** [.tmp_vmlinux1] Error 1
<-- snip -->
That worked with 2.6.26, and these are far less undefined references
than in the cases where libgcc was missing.
[ These symbols are not defined on SH-2 versions of libgcc, so we have to
special case the export there. - Paul ]
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Semaphores are no longer performance-critical, so a generic C
implementation is better for maintainability, debuggability and
extensibility. Thanks to Peter Zijlstra for fixing the lockdep
warning. Thanks to Harvey Harrison for pointing out that the
unlikely() was unnecessary.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
ERROR: "copy_page" [fs/unionfs/unionfs.ko] undefined!
like all the other architectures.
Cc: Erez Zadok <ezk@cs.sunysb.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
