After checking much, I find the problem is caused by "-nostdlib" given to g++, if we set this option to g++ for linking, it will change the out_attr[Tag_FP_arch] to 0, which is generically be 4 for linaro new toolchain.
A right process without -nostdlib doesn't cause ASSERT: #arm-none-linux-gnueabi-g++ main.cpp -mfloat-abi=softfp -mfpu=vfp -march=armv6 -mcpu=arm1136jf-s out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:0, in_attr[i].i:0, in_attr[Tag_ABI_HardFP_use].i:0 ibfd: /home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/../../../../arm-none-linux-gnueabi/lib/crti.o obfd: a.out out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:0, in_attr[i].i:4, in_attr[Tag_ABI_HardFP_use].i:3 ibfd: /home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/crtbegin.o obfd: a.out out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2, in_attr[Tag_ABI_HardFP_use].i:3 /tmp/cc7Krzo3.o a.out out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:0, in_attr[Tag_ABI_HardFP_use].i:0 ibfd: elf-init.oS obfd: a.out out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:4, in_attr[Tag_ABI_HardFP_use].i:3 ibfd: /home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/crtend.o obfd: a.out out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:0, in_attr[Tag_ABI_HardFP_use].i:0 ibfd: /home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/../../../../arm-none-linux-gnueabi/lib/crtn.o obfd: a.out with -nostdlib option, compiling a stand-alone program which doesn't call any library, we will find the first out_attr[i].i becomes 0, which caused ASSERT in the newest binutil with Jie's patch. A wrong process using -nostdlib causes ASSERT: ............... out_attr[i].i:0, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2, in_attr[Tag_ABI_HardFP_use].i:3 ibfd: /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/dir_soc.o obfd: /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk.elf /home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/../../../../arm-none-linux-gnueabi/bin/ld: BFD (GNU Binutils) 2.21 assertion fail /home/vmuser/development/toolchain/build-toolchain/binutils-2.21/bfd/elf32-arm.c:10172 ............ i didn't verify whether gcc has this issue too. Thanks Barry 2011/4/27 Barry Song <21cn...@gmail.com>: > In the Tag_FP_arch case (i=Tag_FP_arch) of > elf32_arm_merge_eabi_attributes (bfd *ibfd, bfd *obfd) function, when > this ASSERT happen, i got some log: > > in_attr[i].i = 2 in_attr[Tag_ABI_HardFP_use].i = 3 > out_attr[i].i = 0 out_attr[Tag_ABI_HardFP_use].i = 3, > > For in_attr[i].i = 2, it means "Use of the v2 FP ISA was permitted > (implies use of the v1 FP ISA) " > For in_attr[Tag_ABI_HardFP_use].i = 3, it means "The user permitted > this entity to use both SP and DP VFP instructions (Note: This is > effectively an explicit version of the default encoded by 0)" > For out_attr[i].i = 0, it means "The user did not permit this entity > to use instructions requiring FP hardware". > > According to Jie's patch, when out_attr[i].i = 0, > out_attr[Tag_ABI_HardFP_use].i should be 0 too. But what i saw is > out_attr[Tag_ABI_HardFP_use].i is also 3, same with > in_attr[Tag_ABI_HardFP_use].i . > > Which compiling option changes out_attr[Tag_ABI_HardFP_use].i to 3? > And which compiling options set out_attr[i].i to 0? > > Thanks > Barry > > 2011/4/28 Barry Song <21cn...@gmail.com>: >> Hi All, >> I found Jie has committed a patch >> "http://sourceware.org/ml/binutils/2010-05/msg00083.html";. >> I am using the newest binary utils(2.21) and encounted the following ASSERT >> in >> arm_elf32.c: >> + if (out_attr[i].i == 0) >> + { >> + BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0); >> >> My compiling options are as below, >> ASM_FLAGS := >> \ >> -gdwarf-2 >> \ >> -mfpu=vfp >> \ >> -mfloat-abi=softfp >> \ >> -mthumb-interwork >> >> C_FLAGS := >> \ >> $(ASM_FLAGS) >> \ >> -O3 -Wno-all >> \ >> -fno-optimize-sibling-calls >> \ >> -mlong-calls >> \ >> -ffunction-sections >> \ >> >> >> >> CPP_FLAGS := >> \ >> -fno-rtti >> \ >> -fno-exceptions >> \ >> >> >> LINK_FLAGS := >> \ >> --gc-sections -nostdlib >> \ >> -L ../stdlib >> \ >> -Wl,--as-needed >> \ >> -Wl,-no-enum-size-warning >> \ >> --cref >> \ >> >> ARFLAGS := >> \ >> rcs >> >> Can anyone give me any tip about why the assert is triggered? >> >> I have reported a bug here: >> http://sourceware.org/bugzilla/show_bug.cgi?id=12700 >> >> But not sure whether it is a bug. >> >> -barry >> > -- Barry Song, Linux Kernel Developer http://21cnbao.blog.51cto.com _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
