The cause should be the endian problem, I guess you were cross-compiling it?
If we compile the kernel for (32bit + big endian) target on an x86
machine(little endian) or reversely, then, it will fail.
Since the scripts/recordmcount is compiled with the local toolchain,
the data structs will be explained according to the local
So, we may need to custom our own elf.h for recordmcount according to
the target type(endian here) of the kernel image:
At first, pass the target information to recordmcount(only a demo
here, we may need to clear it carefully):
diff --git a/scripts/Makefile b/scripts/Makefile
index 2e08810..151fe3e 100644
@@ -11,6 +11,9 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
hostprogs-$(CONFIG_LOGO) += pnmtologo
hostprogs-$(CONFIG_VT) += conmakehash
hostprogs-$(CONFIG_IKCONFIG) += bin2c
+HOSTCFLAGS_recordmcount.o += -DARCH=__$(ARCH)__ \
+ -DBIT=__$(if $(CONFIG_64BIT),64,32)__ \
+ -DENDIAN=__$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)__
hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
always := $(hostprogs-y) $(hostprogs-m)
Then, custom the related data struct(Elf...) for the specific
target(Perhaps we can steal some code from glibc...) and as a result,
no need to check the targets at run-time... just like what we have
done for the Perl version of recordmcount, but for the C version of
recordmcount, we only need to pass the information for one time.
On Mon, Nov 22, 2010 at 7:42 PM, wu zhangjin <email@example.com> wrote:
> Hi, Arnaud
> This only happen at 32bit + big endian, so, perhaps, the symbol
> reltype of bitendian 32bit differs from little endian 32bit, I will
> check it later, thanks!
> Wu Zhangjin
> On Mon, Nov 22, 2010 at 11:04 AM, Arnaud Lacombe <firstname.lastname@example.org> wrote:
>> The build of an `allyesconfig' configuration from v2.6.37-rc3 is
>> failing relatively soon on the following:
>> LD init/mounts.o
>> init/do_mounts.o: bad reloc symbol index (0x20200 >= 0x84) for offset
>> 0x0 in section `__mcount_loc'
>> GNU ld version 2.17
>> The toolchain originated from OpenWRT Kamikaze and is available on their
>> I've not been able to locate the exact point of failure.
>> - Arnaud
>> : http://downloads.openwrt.org/kamikaze/8.09.2/ar71xx/