[OE-core] Building for armv7athf-neon but toolchain is softfp
Khem Raj
raj.khem at gmail.com
Mon Jul 25 14:14:57 UTC 2016
On Monday, July 25, 2016, thilo.cestonaro at ts.fujitsu.com <
thilo.cestonaro at ts.fujitsu.com> wrote:
> 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.
Seems steps are all ok. Can you upload your hello world somewhere.
>
> Cheers,
> Thilo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160725/07caa064/attachment-0002.html>
More information about the Openembedded-core
mailing list