Re: About ARCH=sparc and what to pass to recordmcount.pl
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.
-- Steve
>
> What do you think?
>
> Best regards
> Uwe
>
Reply to: