LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 08-21-2017, 04:39 AM   #16
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Original Poster
Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430

Quote:
Originally Posted by abga View Post
@drmozes

I just got the latest openvpn compiled under Slackware ARM current on one of my Pi2B with: -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
Created a slack package, moved the package over to the Pi0 running Slackware 14.2 SoftFloat, installed it and launched openvpn just to see it not being recognized by the system:

readelf -A /usr/local/sbin/openvpn
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
That's because it's linking against other libraries that are compiled for a different target. If you just compile a piece of code, you'll see that it compiles for the specified target:
Code:
root@stokely:~/# cc -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp  -c t.c -o /tmp/out
root@stokely:~/# readelf -A /tmp/out
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6ZK"
  Tag_CPU_arch: v6KZ

Quote:
While the compiler from the official Slackware ARM 14.2 soft float is broken, it cannot create HardFloat code
It's not broken. glibc is built for for the software floating point ABI, and it's not part of a cross toolchain so there's no reason why it would be able to build for the hard float ABI.
 
Old 08-21-2017, 08:35 AM   #17
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Original Poster
Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430
Quote:
Originally Posted by abga View Post
@drmozes
Many thanks for your quick reply!

I just got the latest openvpn compiled under Slackware ARM current on one of my Pi2B with: -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
Created a slack package, moved the package over to the Pi0 running Slackware 14.2 SoftFloat, installed it and launched openvpn just to see it not being recognized by the system:
This would not work anyway: the software floating point ARM port (14.2 and earlier) uses the software floating point ABI, which is incompatible with the hardware floating point ABI. This is not to do with the architecture (e.g. armv6, armv7) it's to do with the ABI.

Also, on -current (hard float ABI), since the OS is built for armv7 base line, building some a package for armv6 wouldn't make it work on the RPI0 because the RPI0 is only armv6. It's not like on 14.2 where the base line was armv5, so you could optimise your package for a more recent ARM CPU and have it still work (since the newer ARM CPUs are backwards compatible, but obviously the older models cannot be forwards compatible -- they don't have support for instructions that weren't invented when they were designed).
 
Old 08-21-2017, 01:43 PM   #18
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Rep: Reputation: 42
Thanks again for your time and clarifications, I'm starting to understand the limitations of the compiler (or toolchain as it is colloquially called now) on different arm architectures.
I'm sorry for calling the compiler on Slack ARM 14.2-softfloat broken, incomplete should have been used, as it is compiled, as you say, only for supporting soft float, that's why I got the error:
/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory
when trying to produce hard float armv6 code with the -mfloat-abi=hard compiler flag.
(still broken from my perspective )

Regarding the compiler from Slack 14.2-current, it does create native armv6 SoftFloat code that runs without any issues on the pi0. It's only when I use -mfloat-abi=hard the compiler is switching (without asking anyone) to armv7, thus the generated code = garbage = armv7 native code with armv6 specific hardware floating point code. And indeed it links the resulted binaries to the specific armhf libs that do not exist on Slack 14.2 softfloat:
ldd /tmp/build/usr/local/sbin/openvpn | grep armhf
/lib/ld-linux-armhf.so.3 (0x54b8b000)

I was under the impression that the arm implementation in the current compilers is mature enough and that you'd be able to crosscompile at least for the popular armv6/armv7/armv8/etc. architectures and that you could also have all the necessary SF/HF libs coexisting on your system. It looks like the toolchain from Linaro (Raspberry is using it) might be able to do that, although it doesn't come under GPL but EPL.
I guess I was also driven by my enthusiasm to use a Pi2B board (of which I have a few) and compile the necessary HardFloat bins and libs for the Pi0, that drove me to overlook all these interesting details. I might try the Linaro stuff and if I fail I'll switch to Gentoo for the Pi0.

I'm happy with all your help provided on this topic as it is pretty educative and gives a lot of clarifications. You might want to consider amending your original post and add that one is able to create HardFloat code only under Slackware 14.2 ARM - current and under Slackware ARM 14.2 - SoftFloat by rebuilding glibc with softfp he'd be able to compile and use HardFloat binaries but only for compatibility and not performance improvements. Actually, as per the Debian wiki, softfp will generate a lot of overhead and it's pointless to use.
Additionally, I can state that the performance improvement from SoftFloat to HardFloat is just plain MASSIVE! And not only for multimedia stuff but also for a lot of other usual stuff one might want to use on the ARM box. Obviously, for basic functionality, that's bash commands and basic Linux operations SoftFloat will suffice.
 
Old 08-21-2017, 02:48 PM   #19
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Original Poster
Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430
Quote:
Originally Posted by abga View Post

Regarding the compiler from Slack 14.2-current, it does create native armv6 SoftFloat code that runs without any issues on the pi0. It's only when I use -mfloat-abi=hard the compiler is switching (without asking anyone) to armv7, thus the generated code = garbage = armv7 native code with armv6 specific hardware floating point code. And indeed it links the resulted binaries to the specific armhf libs that do not exist on Slack 14.2 softfloat:
ldd /tmp/build/usr/local/sbin/openvpn | grep armhf
/lib/ld-linux-armhf.so.3 (0x54b8b000)
You're still confused about the ABI, it seems so I am going to quote from this URL:

https://raspberrypi.stackexchange.co...es-on-a-soft-f
Quote:
The only problem with hardfloat binaries on softfloat system is application binary interface (ABI) incompatibility. And ABI is about interfacing between libraries. You won't be able to link dynamically to the system libraries if you use wrong ABI. If you provide your own hardfp libraries and configure linker to use them instead of system libraries, there should be no problem with that. Also, you should not have any problems if your binary is statically linked (which means it won't need any dynamic libraries).

It should be possible to compile with other floating point options that your system was created but this may require you to create different toolchain for that. This is because of the libraries that has to be linked to your executable which ABI must match ABI of your executable and hardfp toolchain will only contain hardfp libraries.

You have to worry about ABI compatibility even if you are not calling functions with floating point arguments/return value and not using floating point at all. This is because linker will always mark your executable with ABI flags and will refuse to link it with libraries with different ABI. Unless you are compiling your executable in static mode, it must be linked with at least libc library.
According to the last sentence, you should be able to build statically on -current and run it on 14.2; but the sort of stuff you're building - there's no way you'd build it statically.
Therefore, even if I'd built the toolchain for -current to target armv6, you *still would not be able to run binaries from -current on 14.2* because the ABI's are incompatible.

This and having the toolchain output armv7a binaries despite trying to target armv6, but I explained that already.
This is one of the reasons why Raspbian exists - Debian targeted higher (as we do) than armv6.

Quote:
was under the impression that the arm implementation in the current compilers is mature enough and that you'd be able to crosscompile at least for the popular armv6/armv7/armv8/etc.
You'd need a separate toolchain for armv6 -- the quotes above explain what's going on there.

Quote:
You might want to consider amending your original post and add that one is able to create HardFloat code only under Slackware 14.2 ARM - current and under Slackware ARM 14.2 - SoftFloat by rebuilding glibc with softfp he'd be able to compile and use HardFloat binaries but only for compatibility and not performance improvements. Actually, as per the Debian wiki, softfp will generate a lot of overhead and it's pointless to use.
Yep I will. I have never done it myself and didn't look at what the performance impact was.

Quote:
Additionally, I can state that the performance improvement from SoftFloat to HardFloat is just plain MASSIVE! And not only for multimedia stuff but also for a lot of other usual stuff one might want to use on the ARM box. Obviously, for basic functionality, that's bash commands and basic Linux operations SoftFloat will suffice.
Good to know - I've never measured it. I did notice that the machines running the h/f OS seemed more responsive, but never measured anything.
 
Old 08-21-2017, 04:08 PM   #20
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Rep: Reputation: 42
I was confused about the ABI and thanks again for your patience and effort in explaining it to me. You're the ARM expert! It starts to look like science to me BTW, with all this double-trouble = platform-specific & ABI-specific
Please add SoftFloat / HardFloat in your compilation explanations, it's confusing without them when related to ABI.

Basically, if I was to rebuild glibc for armv6, the only option I have is to use softfp for system compatibility (for the already in place binaries). If I'd rebuild glibc for armv6 with -mfloat-abi=hard, anyways I don't have a compiler (toolchain) under Slack able to do that, then due to the incompatible generated ABI I'll mess up the whole Slack 14.2 SoftFloat system. What a pity

On HardFloat performance, I remember installing Slack on my first Pi2B some years ago and by having some issues with the arm-mini-root images I only succeeded installing Slack ARM 14.2 SoftFloat for the first time (I was a noob - still am with respect to ARM). After a week or so I managed to get Slack 14.2 current HardFloat and it was like I got almost a doubling in performance on the services / programs I was using. I would like to add that I'm always recompiling the core components I'm using with -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard and I'm still amazed to this very day about how fast Slack HF on these little Pi2B "toys" is.

By looking up on this thread I saw louigi600's post about the kernel requirements for being able to "ingest" vfp code and pass it to the FPU. In this respect I checked the .config file from the Raspbian 4.4.50+ kernel and learned that it was built with generic VFP support:
#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y

Just for clarification, for those who don't know about, the folks at Raspberry are issuing two (there will be 3 with the Pi3B 64bit) Raspberry Pi specific kernel versions (and modules in /lib/modules) with their Raspbian image.
For example ending in "+" for armv6 and "v7+" for armv7:
4.4.50+
4.4.50-v7+
- corresponding to:
/boot/kernel.img
/boot/kernel7.img
In order to check if you have a kernel that supports HardFloat vfp operations you'd need to check the kernel .config file and to obtain it, run the following:
modprobe configs
config.gz is to be found in /proc
cp /proc/config.gz /your-folder
rmmod configs
cd /your-folder
gunzip config.gz
mv config .config
- voila! edit .config and check for whatever you're looking after.
 
Old 08-22-2017, 06:57 PM   #21
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Rep: Reputation: 42
I'm kinda perseverent by nature, it's a "defect" I got along with, and I've never gave up on Slack, at least not in the last ~18 years and I'm not ready to give up on it now due to this ARM mess.

In trying to understand the limitations of the compilers that come with both Slack ARM 14.2 SofFloat and Slack 14.2 ARM current - HardFloat and what I would need to prepare to produce armv6 HardFloat code, I've come across this very informative post:
https://stackoverflow.com/questions/...ith-a-single-g

and learned that both these compilers were built without multilib support.


Additionally, I've learned that with the Linaro compiler using -mfloat-abi=softfp is more restrictive as it looks in their documentation:
https://wiki.linaro.org/Linaro-arm-hardfloat
"
While soft/softfp are forwards compatible, ie. a 'soft' app can run on a softfp system -but not vice versa- a 'hardfloat' application can run on neither of those systems. This means that in order to use hardfloat the system has to be completely rebuilt for hardfloat, down to the last application.
"

Extra - HardFloat performance measurements from Linaro:
https://wiki.linaro.org/Linaro-arm-hardfloat
"
It has been shown [1] that a typical application built with hardfloat is 5-40% faster than the softfp version. In cases of heavy floating point use, the speed increase can go even further -eg. povray was proven to be >200% faster! [2] "

I guess, my approach to get a Slack armv6 HardFloat port will be to get a cross-compiler (gcc and not the one from Linaro) with multilibs first, then manually modify the SlackBuilds (adding armv6 HF flags) and building the miniroot and all the Slack packages I need from source. I'm really considering to do this on a powerful x86 system, suspecting that on a Pi2B it might take some days, and I'm not sure yet how to get such a cross-compiler environment producing arm code on a x86 box. Time to get busy!
 
Old 08-28-2017, 09:06 PM   #22
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Rep: Reputation: 42
@drmozes

You might want to consider removing or editing your statement from the first post (again), because it is still confusing:
Quote:
Q. Can I recompile some of the packages in Slackware ARM to be hard float and leave the rest as Soft Float?

Yes!

Have a look through this article that explains about rebuilding some of the core components to use hard float:

http://mindplusplus.wordpress.com/20...-raspberry-pi/
- Slackware ARM 14.2 - SoftFloat (that's the only "rest as Soft Float") doesn't provide you with a compiler able to generate HardFloat code
- the person who wrote that How-To never states, or maybe corrected recently his blog entry, that by rebuilding some of the core components (with softfp support) you might be able to run HardFloat code on the SoftFloat system. He only states that he "optimized" the SoftFloat system. What softfp is actually doing, is just emulating HardFloat calls towards the kernel/FPU.
https://mindplusplus.wordpress.com/2...-raspberry-pi/
- as discussed before, softfp might create more overhead than simple soft and I'm still not sure why it was created in the first place:
https://wiki.debian.org/ArmHardFloatPort/VfpComparison
- the only way to run HardFloat code on a SoftFloat system is to use HardFloat binaries/programs that are statically linked with their depending libs and copy over those libs together with the binaries too.
 
Old 08-29-2017, 04:11 AM   #23
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Original Poster
Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430
Quote:
Originally Posted by abga View Post
@drmozes

You might want to consider removing or editing your statement from the first post (again), because it is still confusing:


- Slackware ARM 14.2 - SoftFloat (that's the only "rest as Soft Float") doesn't provide you with a compiler able to generate HardFloat code
- the person who wrote that How-To never states, or maybe corrected recently his blog entry, that by rebuilding some of the core components (with softfp support) you might be able to run HardFloat code on the SoftFloat system. He only states that he "optimized" the SoftFloat system. What softfp is actually doing, is just emulating HardFloat calls towards the kernel/FPU.
https://mindplusplus.wordpress.com/2...-raspberry-pi/
- as discussed before, softfp might create more overhead than simple soft and I'm still not sure why it was created in the first place:
https://wiki.debian.org/ArmHardFloatPort/VfpComparison
- the only way to run HardFloat code on a SoftFloat system is to use HardFloat binaries/programs that are statically linked with their depending libs and copy over those libs together with the binaries too.

Unfortunately I cannot edit the post - probably because it's years old.
I think that this discussion itself should suffice to explain the situation.
I might look to get the 'sticky' flag removed from the thread when a stable release of the hard float port is released, at which point it's 'just another release' (at least to me!) to which there is either no upgrade path, or a full reinstallation upon appropriate hardware.
 
Old 08-29-2017, 03:21 PM   #24
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Rep: Reputation: 42
@drmozes

Quote:
I think that this discussion itself should suffice to explain the situation.
I hope that too and also apologize for any of my posts that might have created some confusion. It was a learning experience on my side.

_______


There is a general question I have about the NEON SIMD instructions (introduced with Cortex-A7 and apparently becoming only optional with Cortex-A9) and considered to use this thread to address it. It's also related to HardFloat and VFP instructions.

Just a short intro and some details for the ones who are new with these SIMD instructions:
https://en.wikipedia.org/wiki/ARM_ar...IMD_.28NEON.29
https://developer.arm.com/technologies/neon
http://infocenter.arm.com/help/topic.../BABIIFHA.html
https://stackoverflow.com/questions/...n-how-to-start

There is a very good article with respect to ARM compilation and VFP options - in which it is described that one should use the -O3 gcc compiler optimization flag in order to start the auto-vectorizer and produce optimized VFP code (Section Adding floating-point and SIMD & Vectorizing floating-point operations):

https://community.arm.com/tools/b/bl...-command-lines

In another post it is stated that: floating-point operations will not be used by GCC's auto-vectorization pass unless `-funsafe-math-optimizations' is also specified. But I was able to generate (at least readelf is reporting: Tag_FP_arch: VFPv4 - Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC) NEON VFP code without using -funsafe-math-optimizations, but only -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard

https://stackoverflow.com/questions/...nd-compare-flo

My question:
Slack ARM -current HF is mainly compiled to use VFPv3-D16 VFP/FPU instructions and I'm not sure how NEON instructions are handled if an userland binary is compiled to use them (FFMPEG for instance has a NEON configuration switch and NEON specific source code). Are these NEON instructions passed directly to the kernel/FPU even if the system (some other dependent shared libs) is VFPv3-D16?

Last edited by abga; 08-29-2017 at 03:36 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
SlackwareARM on RaspberryPI and soft/hard float andrixnet Slackware - ARM 20 10-08-2014 09:02 PM
Hard float/soft float interndan Slackware - ARM 5 08-01-2014 11:23 AM
[SOLVED] gcc 4.6.3 'invalid operands to binary % ( have 'float' and 'float' ) error curious95 Programming 6 02-22-2013 09:51 AM
count digits of a float || convert float to string nadroj Programming 6 07-11-2005 05:52 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 10:31 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration