(Change the wrong Email address jreiseer@xxxxxxxxxxxx to jreiser@xxxxxxxxxxxx) On Mon, Nov 22, 2010 at 10:57 PM, wu zhangjin <wuzhangjin@xxxxxxxxx> wrote: > Hi, > > 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 > configuration(endian...). > > 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. > > Regard, > Wu Zhangjin > > On Mon, Nov 22, 2010 at 7:42 PM, wu zhangjin <wuzhangjin@xxxxxxxxx> 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! >> >> Regards, >> Wu Zhangjin >> >> On Mon, Nov 22, 2010 at 11:04 AM, Arnaud Lacombe <lacombar@xxxxxxxxx> wrote: >>> Hi, >>> >>> The build of an `allyesconfig' configuration from v2.6.37-rc3 is >>> failing relatively soon on the following: >>> >>> [...] >>> LD init/mounts.o >>> /OpenWrt-SDK-ar71xx-for-Linux-i686/staging_dir/toolchain-mips_gcc4.1.2/bin/mips-linux-ld: >>> init/do_mounts.o: bad reloc symbol index (0x20200 >= 0x84) for offset >>> 0x0 in section `__mcount_loc' >>> >>> /OpenWrt-SDK-ar71xx-for-Linux-i686/staging_dir/toolchain-mips_gcc4.1.2/bin/mips-linux-ld >>> -v >>> GNU ld version 2.17 >>> >>> The toolchain originated from OpenWRT Kamikaze and is available on their FTP[0]. >>> >>> I've not been able to locate the exact point of failure. >>> >>> - Arnaud >>> >>> [0]: http://downloads.openwrt.org/kamikaze/8.09.2/ar71xx/ >>> >>> >> >
