This adds a general CONFIG_MCOUNT in order to permit mcount generation
without ftrace support. This is primarily for allowing platforms to
enable aggressive stack overflow checking without having to enable ftrace
support. Based on the sparc64 implementation.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Add both dynamic and static function graph tracer support for sh.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
We chan't share code for udivsi3 and udivsi3_i4, because they
have a different clobber list. Copy udivsi3 from gcc-4.1.2.
As shown in arch/sh/lib/udivsi3.S (and -Os.S),
.global __udivsi3_i4i
.global __udivsi3_i4
.global __udivsi3
__udivsi3_i4i:
...
Three symbols are sharing one code, which is actually udivsi3_i4i.
But, this results unwanted code with gcc 4.1.
In gcc, these three are treated as pseudo instructions that have
their own clobber list apart from the usual calling convention.
According to sh's machine description. The clobber list is as
follows:
- udivsi3_i4i : t,r1,pr,mach,macl
- udivsi3_i4 : t,r0,r1,r4,r5,pr,dr0,dr2,dr4
- udivsi3 : t,r4,pr
The caller of udivsi3 will be left with a broken r1 and mac*.
gcc-4.1.x and older(at least to 3.4) generate udivsi3.
ST's gcc-4.1.1 seems to be OK because it has _i4i.
Signed-off-by: Takashi YOSHII <yoshii.takashi@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This moves in the necessary libgcc bits for SUPERH32 and drops the
libgcc linking for the regular targets. This in turn allows us to rip
out quite a few hacks both in sh_ksyms_32 and arch/sh/Makefile.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Previously we've been handling udivdi3 references and wrapping
them in to div64_32() automatically. This doesn't get a lot of
use, however, and as akpm noted in the recent thread on l-k:
http://lkml.org/lkml/2007/2/27/241
we're better off simply ripping it out and going the do_div()
route if there happen to be any places that need it.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Paul Mundt