On Mon, 2011-08-15 at 11:33 -0400, Steven Rostedt wrote:
> On Mon, 2011-08-15 at 17:21 +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > when I enable CONFIG_FUNCTION_TRACER and CONFIG_DYNAMIC_FTRACE for the
> > Debian kernel the build fails with:
> >
> > CC init/do_mounts_initrd.o
> > Arch sparc is not supported with CONFIG_FTRACE_MCOUNT_RECORD at
> > .../scripts/recordmcount.pl line 368.
> >
> > This happens because the kernel package build scripts call
> >
> > make ARCH=sparc
> >
> > $(ARCH) is passed to scripts/recordmcount.pl and the latter only knows
> > about "sparc64".
> >
> > There are several options to fix that:
> >
> > a) let the package pass ARCH=sparc64 instead of ARCH=sparc
> > Then sparc would be the only architecture that doesn't pass the
> > (Debian) arch here. I'm not sure there are other reasons to stick to
> > ARCH=sparc. Bastian?
> > It seems only recordmcount.pl chokes on that because Debian uses
> > ARCH=sparc since at least 2.6.32, probably much longer.
> >
> > b) pass SRCARCH instead of ARCH to recordmcount.pl and do
> > s/sparc64/sparc/ in recordmcount.pl.
>
> b may break other archs.
>
> >
> > c) do the following in recordmcount.pl:
> > if ($arch =~ /sparc(32|64)?/) {
> > if ($bits == 64) {
> > $arch = "sparc64";
> > } else {
> > $arch = "sparc"; # or "sparc32"?
> > }
> > }
>
> c is fine with me.
>
> >
> > Something like that is already done for x86.
> >
> > Personally I prefer b), but I'm not sure I see all the consequences.
>
> It may break other archs. I rather not do a change that affects all
> archs. This is a sparc specific problem. The solution should only affect
> sparc. Which to me is option c.
>
Actually, I think option d) is the best.
d) have sparc support recordmcount.c
-- Steve
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1313422823.15704.8.ca...@gandalf.stny.rr.com
