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 21cnbao@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 21cnbao@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