[OE-core] Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro at ts.fujitsu.com]

Hey Khem!

Thanks for your answer!

> > 
> > I want to build my own dist and a sdk for it. The dist is working and is as expected by the DEFAULT_TUNE of "armv7athf-neon", hardfp.
> > 
> > But the TARGET_SYS in the bitbake header always tells me, that the toolchain it uses is "...-gnueabi". Not "hf" in there?!
> > Thats the first thing what I can't figure out.
> We do not rely on target triplet. calling convention is determined by
> -mfloat-abi switch that is what OE relies on.
> 

Ok. Understood. But even when I build with -mfloat-abi=hard (and the VFP Register Entry is there with readelf, on build machine and target).
I can't do ldd helloworld on the target. 



> > 
> > The other thing is, when I now use the sdk, after successfully populating it, the toolchain in there has the default -mfloat-abi=softfp ...
> > But even when I compile with -mfloat-abi=hard, the executable which I get, segfaults on the target and ldd tells me "not a dynamic executable".
> > But readelf (on the target or host) tells me, that "Tag_ABI_VFP_args: VFP registers" (which is detection for hardfp, right?).
> > And I miss the "hf" at the gnueabi in the sdk toolchain.
> Is target running the image build by you as well ? and prefereably
> build in same sandbox as the SDK
> if not then you need to figure out how the image was built.  what is
> output of ls /lib/ld-*

It's a krogoth build with callconvention-hard enabled via DEFAULTTUNE.
And I have one recipe for the image and one for the sdk toolchain. So the "Build" are two bitbake calls.

HOST with SDK:
$ . /opt/amana-sdk/sdk-environment
$ echo $CXX
arm-magna-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard --sysroot=/opt/amana-sdk/4.0-1469450812/sysroots/armv7ahf-neon-magna-linux-gnueabi
$ ${CXX} -o helloworld helloworld.cpp 
$ scp helloworld target:/usr/bin


TARGET:
# ldd /lib/libc.so.6 
	/lib/ld-linux-armhf.so.3 (0xb6f41000)
# ls -l /lib/ld-*
-rwxr-xr-x    1 root     root        134396 Jul 22 10:56 /lib/ld-2.23.so
lrwxrwxrwx    1 root     root            10 Jul 22 10:56 /lib/ld-linux-armhf.so.3 -> ld-2.23.so

# /usr/bin/helloworld
Segmentation fault

# ldd /usr/bin/helloworld 
	not a dynamic executable

# readelf -A /usr/bin/helloworld 
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

# readelf -h /usr/bin/helloworld 
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x85f4
  Start of program headers:          52 (bytes into file)
  Start of section headers:          42264 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           40 (bytes)
  Number of section headers:         39
  Section header string table index: 36


Any idea what's wrong here??
I don't get it.

Cheers,
Thilo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3847 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160725/473798f1/attachment-0002.bin>