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 > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
