Building for armv7athf-neon but toolchain is softfp

Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

Hey all!

Hopefully this is no dumb question but I can't find any solution currently.

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.

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.


my program was the following and it compiled without any warnings or errors:
----------
#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
	cout << "Hello World!" << endl;
	return 0;
}
--------------

I also tried Default tune to set to "cortexa8thf-neon" which had the same result.


Any hints why the toolchain is softfp by default?

Regards,
Thilo

PS: When I use the ubuntu arm-linux-gnueabihf-g++ with the sdk sysroot, the helloworld program works as expected.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[Khem Raj]

On Fri, Jul 22, 2016 at 6:39 AM, thilo.cestonaro@ts.fujitsu.com
<thilo.cestonaro@ts.fujitsu.com> wrote:
> Hey all!
>
> Hopefully this is no dumb question but I can't find any solution currently.
>
> 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.

>
> 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-*

>
>
> my program was the following and it compiled without any warnings or errors:
> ----------
> #include <iostream>
>
> using namespace std;
>
> int main(int argc, char *argv[])
> {
>         cout << "Hello World!" << endl;
>         return 0;
> }
> --------------
>
> I also tried Default tune to set to "cortexa8thf-neon" which had the same result.
>
>
> Any hints why the toolchain is softfp by default?
>
> Regards,
> Thilo
>
> PS: When I use the ubuntu arm-linux-gnueabihf-g++ with the sdk sysroot, the helloworld program works as expected.
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- 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 --]

Re: Building for armv7athf-neon but toolchain is softfp

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 4333 bytes --]

On Monday, July 25, 2016, thilo.cestonaro@ts.fujitsu.com <
thilo.cestonaro@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

[-- Attachment #2: Type: text/html, Size: 5604 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]

Hey Khem,

> Seems steps are all ok. Can you upload your hello world somewhere.

http://thilo.cestona.ro/~ephraim/public/helloworld.zip

Hope you can find out whats going on here :).

Cheers,
Thilo

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]


> On Jul 26, 2016, at 2:39 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> 
> Hey Khem,
> 
>> Seems steps are all ok. Can you upload your hello world somewhere.
> 
> http://thilo.cestona.ro/~ephraim/public/helloworld.zip
> 
> Hope you can find out whats going on here :).
> 

This seems to contain C++ it seems. Can you try a simple C hello.c and see if that works.

> Cheers,
> Thilo


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Hey Khem!

I changed the helloworld to the following, but it still doesn't work.
------------------------
#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("Hello World!\n");
	return 0;
}
-------------------------

I updated the Zip of the Url to have the C-Helloworld.

Cheers,
Thilo

On Mi, 2016-07-27 at 02:57 -0700, Khem Raj wrote:
> > 
> > On Jul 26, 2016, at 2:39 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> > 
> > Hey Khem,
> > 
> > > 
> > > Seems steps are all ok. Can you upload your hello world somewhere.
> > http://thilo.cestona.ro/~ephraim/public/helloworld.zip
> > 
> > Hope you can find out whats going on here :).
> > 
> This seems to contain C++ it seems. Can you try a simple C hello.c and see if that works.
> 
> > 
> > Cheers,
> > Thilo

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

Hey Khem,

I figured, when I do the compile in 2 steps, so compile then link and change the link command to use the ubuntu arm-linux-gnueabihf-gcc instead of the gcc from the sdk, the binary is useable.

I hope that helps a bit!

Cheers,
Thilo


On Mi, 2016-07-27 at 02:57 -0700, Khem Raj wrote:
> > 
> > On Jul 26, 2016, at 2:39 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> > 
> > Hey Khem,
> > 
> > > 
> > > Seems steps are all ok. Can you upload your hello world somewhere.
> > http://thilo.cestona.ro/~ephraim/public/helloworld.zip
> > 
> > Hope you can find out whats going on here :).
> > 
> This seems to contain C++ it seems. Can you try a simple C hello.c and see if that works.
> 
> > 
> > Cheers,
> > Thilo

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]


> On Jul 27, 2016, at 5:14 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> 
> Hey Khem,
> 
> I figured, when I do the compile in 2 steps, so compile then link and change the link command to use the ubuntu arm-linux-gnueabihf-gcc instead of the gcc from the sdk, the binary is useable.

this could be a gnu_hash issue then. Can you add -Wl,--hash-style=gnu to compiler cmd when linking using OE SDK

> 
> I hope that helps a bit!
> 
> Cheers,
> Thilo
> 
> 
> On Mi, 2016-07-27 at 02:57 -0700, Khem Raj wrote:
>>> 
>>> On Jul 26, 2016, at 2:39 AM, thilo.cestonaro@ts.fujitsu.com wrote:
>>> 
>>> Hey Khem,
>>> 
>>>> 
>>>> Seems steps are all ok. Can you upload your hello world somewhere.
>>> http://thilo.cestona.ro/~ephraim/public/helloworld.zip
>>> 
>>> Hope you can find out whats going on here :).
>>> 
>> This seems to contain C++ it seems. Can you try a simple C hello.c and see if that works.
>> 
>>> 
>>> Cheers,
>>> Thilo


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Mi, 2016-07-27 at 08:18 -0700, Khem Raj wrote:
> > 
> > On Jul 27, 2016, at 5:14 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> > 
> > Hey Khem,
> > 
> > I figured, when I do the compile in 2 steps, so compile then link and change the link command to use the ubuntu arm-linux-gnueabihf-gcc instead of the gcc from the sdk, the binary is useable.
> this could be a gnu_hash issue then. Can you add -Wl,--hash-style=gnu to compiler cmd when linking using OE SDK
> 
No success :( ... I tested it, altough it was already included in LDFLAGS from sdk env. Added it the the compile command and the link command. Doesn't change anything :(.
Any other idea?

Cheers,
Thilo

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[thilo.cestonaro]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

Hey Khem!

Thanks for your help!! We used to have an extra ld-script which once worked. It was injected into the sdk in our sdk-install script by moving the toolchain ld to ld.real and creating a script which
calls the ld.real with the ldscript as parameter. I didn't introduce this in the sdk install, so I thought it is from oe-core. But just found out that we create that ld script usage and removed it.

That fix the executables. I guess, as we did the step from gcc 4 to 5, it was for gcc 4 and broke gcc 5. 

Anyway thanks for your patience and time!

Cheers,
Thilo

On Do, 2016-07-28 at 07:11 +0000, thilo.cestonaro@ts.fujitsu.com wrote:
> On Mi, 2016-07-27 at 08:18 -0700, Khem Raj wrote:
> > 
> > > 
> > > 
> > > On Jul 27, 2016, at 5:14 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> > > 
> > > Hey Khem,
> > > 
> > > I figured, when I do the compile in 2 steps, so compile then link and change the link command to use the ubuntu arm-linux-gnueabihf-gcc instead of the gcc from the sdk, the binary is useable.
> > this could be a gnu_hash issue then. Can you add -Wl,--hash-style=gnu to compiler cmd when linking using OE SDK
> > 
> No success :( ... I tested it, altough it was already included in LDFLAGS from sdk env. Added it the the compile command and the link command. Doesn't change anything :(.
> Any other idea?
> 
> Cheers,
> Thilo
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]

Re: Building for armv7athf-neon but toolchain is softfp

[Khem Raj]

On Thu, Jul 28, 2016 at 1:18 AM, thilo.cestonaro@ts.fujitsu.com
<thilo.cestonaro@ts.fujitsu.com> wrote:
> Hey Khem!
>
> Thanks for your help!! We used to have an extra ld-script which once worked. It was injected into the sdk in our sdk-install script by moving the toolchain ld to ld.real and creating a script which
> calls the ld.real with the ldscript as parameter. I didn't introduce this in the sdk install, so I thought it is from oe-core. But just found out that we create that ld script usage and removed it.
>

avoid such hacks in future. Or mention them when you describe the problem.

> That fix the executables. I guess, as we did the step from gcc 4 to 5, it was for gcc 4 and broke gcc 5.
>
> Anyway thanks for your patience and time!
>
> Cheers,
> Thilo
>
> On Do, 2016-07-28 at 07:11 +0000, thilo.cestonaro@ts.fujitsu.com wrote:
>> On Mi, 2016-07-27 at 08:18 -0700, Khem Raj wrote:
>> >
>> > >
>> > >
>> > > On Jul 27, 2016, at 5:14 AM, thilo.cestonaro@ts.fujitsu.com wrote:
>> > >
>> > > Hey Khem,
>> > >
>> > > I figured, when I do the compile in 2 steps, so compile then link and change the link command to use the ubuntu arm-linux-gnueabihf-gcc instead of the gcc from the sdk, the binary is useable.
>> > this could be a gnu_hash issue then. Can you add -Wl,--hash-style=gnu to compiler cmd when linking using OE SDK
>> >
>> No success :( ... I tested it, altough it was already included in LDFLAGS from sdk env. Added it the the compile command and the link command. Doesn't change anything :(.
>> Any other idea?
>>
>> Cheers,
>> Thilo
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core