[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