Re: About ARCH=sparc and what to pass to recordmcount.pl
On Mon, Aug 15, 2011 at 11:40:23AM -0400, Steven Rostedt wrote:
> 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.
I think it doesn't, but in the presence of d) below I won't argue.
> > > 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
I only have access to a sparc chroot without the possibility to make a
run test, so if you want to test d), it's just adding
select HAVE_C_RECORDMCOUNT
to config SPARC64. Building a kernel with it seems to work (and should
be faster).
If you're lazy and a Debian-sparc user I can provide you a kernel
package to test that. Just tell me by private mail.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Reply to: