From: "thilo.cestonaro@ts.fujitsu.com" <thilo.cestonaro@ts.fujitsu.com>
To: "raj.khem@gmail.com" <raj.khem@gmail.com>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: Building for armv7athf-neon but toolchain is softfp
Date: Mon, 25 Jul 2016 14:06:26 +0000 [thread overview]
Message-ID: <1469455403.6896.29.camel@ts.fujitsu.com> (raw)
In-Reply-To: <CAMKF1srBan-tupS7qGb3kDnAn-2-u8dox3vFk5ssGwQLzeGaHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4261 bytes --]
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
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]
next prev parent reply other threads:[~2016-07-25 14:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 13:39 Building for armv7athf-neon but toolchain is softfp thilo.cestonaro
2016-07-22 14:10 ` Khem Raj
2016-07-25 14:06 ` thilo.cestonaro [this message]
2016-07-25 14:14 ` Khem Raj
2016-07-26 9:39 ` thilo.cestonaro
2016-07-27 9:57 ` Khem Raj
2016-07-27 12:06 ` thilo.cestonaro
2016-07-27 12:14 ` thilo.cestonaro
2016-07-27 15:18 ` Khem Raj
2016-07-28 7:11 ` thilo.cestonaro
2016-07-28 8:18 ` thilo.cestonaro
2016-07-28 13:55 ` Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1469455403.6896.29.camel@ts.fujitsu.com \
--to=thilo.cestonaro@ts.fujitsu.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.