Comment 13 for bug 1304267

Hi Zhengqiang,
I have found the root cause.

The following command can get correct results
./gcc/xgcc -print-multi-lib
.;
armv7a-linux-gnueabi;@marm@march=armv7-a@mtune=cortex-a9@mfloat-abi=softfp@mfpu=vfpv3
armv6k-linux-gnueabi;@marm@march=armv6k@mtune=arm1136j-s@mfloat-abi=soft@Wa,-mfpu=softvfp

./gcc/xgcc -print-multi-directory -marm -march=armv7-a
-mtune=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3
armv7a-linux-gnueabi

But this command can't get the correct multi-directory
./gcc/xgcc -print-multi-directory -marm -march=armv6k
-mtune=arm1136j-s -mfloat-abi=soft -Wa,-mfpu=softvfp
.
The result is .(dot), instead of armv6k-linux-gnueabi

I don't know if there's something wrong with my t-mlibs file, here is
my t-mlibs file, could you please help check and give me some
suggestions:

# A set of predefined MULTILIB for different ARM targets.
# Through the configure option --with-multilib-list, user can customize the
# final MULTILIB implementation.

comma := ,
space :=
space +=

MULTILIB_OPTIONS = marm
MULTILIB_DIRNAMES = arm
MULTILIB_OPTIONS += march=armv6k
MULTILIB_DIRNAMES += armv6k
MULTILIB_OPTIONS += march=armv7-a
MULTILIB_DIRNAMES += armv7-a
MULTILIB_OPTIONS += mtune=arm1136j-s
MULTILIB_DIRNAMES += arm1136j-s
MULTILIB_OPTIONS += mtune=cortex-a9
MULTILIB_DIRNAMES += cortex-a9
MULTILIB_OPTIONS += mfloat-abi=soft
MULTILIB_DIRNAMES += soft
MULTILIB_OPTIONS += mfloat-abi=softfp
MULTILIB_DIRNAMES += softfp
MULTILIB_OPTIONS += mfpu=vfpv3
MULTILIB_DIRNAMES += vfpv3
MULTILIB_OPTIONS += Wa,-mfpu=softvfp
MULTILIB_DIRNAMES += softvfp

MULTILIB_EXCEPTIONS =

MULTILIB_REQUIRED =
marm/march=armv7-a/mtune=cortex-a9/mfloat-abi=softfp/mfpu=vfpv3
MULTILIB_OSDIRNAMES =
marm/march.armv7-a/mtune.cortex-a9/mfloat-abi.softfp/mfpu.vfpv3=!armv7a-linux-gnueabi

MULTILIB_REQUIRED +=
marm/march=armv6k/mtune=arm1136j-s/mfloat-abi=soft/Wa,-mfpu=softvfp
MULTILIB_OSDIRNAMES +=
marm/march.armv6k/mtune.arm1136j-s/mfloat-abi.soft/Wa,-mfpu.softvfp=!armv6k-linux-gnueabi

On Wed, Apr 9, 2014 at 5:29 PM, Zhenqiang Chen
<email address hidden> wrote:
> I do not think it is a libgcc bug. If your multilib option is correct,
> libgcc should find the correct path.
>
> Can you show me the multilib options?
>
> ./gcc/xgcc --print-multi-lib
>
> And all your libc layout in your install dir?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1304267
>
> Title:
> Linaro arm linux gnueabihf gcc always add Tag_FP_arch: VFPv3-D16 when
> building .S file with -mfloat-abi=soft
>
> Status in Linaro GCC:
> Invalid
>
> Bug description:
> I have a ASM file with extension .S
> After I build this file with option
> "-marm -march=armv4t -mfloat-abi=soft -c xxx.S -o xxx.o"
> I checked xxx.o with command "arm-linux-gnueabihf-readelf -A xxx.o"
>
> And the output is
> Attribute Section: aeabi
> File Attributes
> Tag_CPU_name: "4t"
> Tag_CPU_arch: v4T
> Tag_ARM_ISA_use: Yes
> Tag_THUMB_ISA_use: Thumb-1
> Tag_FP_arch: VFPv3-D16
>
> I noticed tag " Tag_FP_arch: VFPv3-D16", this tag prevents this xxx.o
> from linking with other .o files.
>
> However, when building .c or .cpp files, the generated .o files don't
> have " Tag_FP_arch: VFPv3-D16"
>
> It seems that AS doen't respect option "-mfloat-abi=soft" and always
> add "Tag_FP_arch: VFPv3-D16" to the genrated .o files
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gcc-linaro/+bug/1304267/+subscriptions