(Change the wrong Email address email@example.com to jreiser@BitWagon.com)
On Mon, Nov 22, 2010 at 10:57 PM, wu zhangjin <firstname.lastname@example.org> wrote:
> 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
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -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.
> Wu Zhangjin
> 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/