[SOLVED] Compiler behavior on both SlackARM 14.2 SF and SlackARM current after latest updates Aug 2017

abga · 08-24-2017, 12:18 AM

I was about to finalize a compilation how-to for FFMPEG last evening and by "testing before publishing" my instructions I've noticed that the compiler on both Slack 14.2 SF and Slack ARM current HF are producing inconsistent results. I've performed my last update on both systems around 13-18 Aug 2017 and noticed that glibc was updated.

Here are the findings:
On a pi2B (armv7) running SlackARM-current-HF by trying to produce armv6 SF code:
uname -a
Linux Goofy 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l BCM2709 GNU/Linux
x264# ./configure --enable-shared --disable-win32thread --enable-strip --extra-cflags='-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft'
No working C compiler found.

On a pi0 (armv6) running SlackARM-14.2-SF trying to produce armv6 SF code:
uname -a
Linux JunkPi 4.4.50+ #970 Mon Feb 20 19:12:50 GMT 2017 armv6l BCM2708 GNU/Linux
x264# ./configure --enable-shared --disable-win32thread --enable-strip --extra-cflags='-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft'

The result:
readelf -A libx264.so.152
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_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

Compared with the result compiled before the update with the same ./configure switches:
ls -al /usr/local/lib/libx264.so
lrwxrwxrwx 1 root root 14 Aug 14 11:55 /usr/local/lib/libx264.so -> libx264.so.152
readelf -A /usr/local/lib/libx264.so
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6ZK"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
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_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

I've also noticed that on the pi0 - SlackARM 14.2 SF when compiling without any CFLAGS options I get armv8 code with NEON FP code:
....
gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -mcpu=cortex-a8 -mfpu=neon
....
readelf -A libx264.so.152
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-A8"
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_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

I wish my pi0 had such a CPU, not to mention how happy I would have been to get NEON implementation in the FPU

Please check what's going on.

I edited the post to add my latest observations:
- I've done (actually it's an automated script that runs in the morning) the packages update on 13 Aug 2017 (when glibc was updated) and on 18 Aug 2017 and on 14&15 August I was still compiling without any issues. Only after 18 August and after rebooting both systems I started to observe the issues.

abga · 08-24-2017, 01:54 AM

The historical list of the updates on Slack ARM current (the pi0 running Slack 14.2 SF is N/A ATM):

-rw-r--r-- 1 root root 1001 Aug 18 04:33 xorg-server-xvfb-1.19.3-arm-2
-rw-r--r-- 1 root root 907 Aug 18 04:33 xorg-server-xnest-1.19.3-arm-2
-rw-r--r-- 1 root root 686 Aug 18 04:32 xorg-server-xephyr-1.19.3-arm-2
-rw-r--r-- 1 root root 7622 Aug 18 04:32 xorg-server-1.19.3-arm-2
-rw-r--r-- 1 root root 11635 Aug 18 04:32 tk-8.6.7-arm-1
-rw-r--r-- 1 root root 17678 Aug 18 04:31 tcl-8.6.7-arm-1
-rw-r--r-- 1 root root 13702 Aug 18 04:30 subversion-1.9.7-arm-1
-rw-r--r-- 1 root root 51770 Aug 18 04:30 samba-4.6.7-arm-1
-rw-r--r-- 1 root root 13054 Aug 18 04:28 poppler-data-0.4.8-noarch-1
-rw-r--r-- 1 root root 2620 Aug 18 04:27 mpg123-1.25.6-arm-1
-rw-r--r-- 1 root root 45462 Aug 18 04:27 mercurial-4.3.1-arm-1
-rw-r--r-- 1 root root 20279 Aug 18 04:26 mariadb-10.0.32-arm-1
-rw-r--r-- 1 root root 13899 Aug 18 04:23 libsoup-2.58.2-arm-1
-rw-r--r-- 1 root root 61382 Aug 18 04:22 git-2.14.1-arm-1
-rw-r--r-- 1 root root 5390 Aug 18 04:21 cups-filters-1.16.1-arm-1
-rw-r--r-- 1 root root 31267 Aug 18 04:21 cups-2.2.4-arm-2
-rw-r--r-- 1 root root 128985 Aug 18 04:21 cmake-3.9.1-arm-1
-rw-r--r-- 1 root root 1664 Aug 13 03:22 xf86-input-wacom-0.35.0-arm-1
-rw-r--r-- 1 root root 1401 Aug 13 03:22 vim-gvim-8.0.0876-arm-1
-rw-r--r-- 1 root root 72732 Aug 13 03:22 vim-8.0.0876-arm-1
-rw-r--r-- 1 root root 9867 Aug 13 03:21 tumbler-0.2.0-arm-1
-rw-r--r-- 1 root root 1249 Aug 13 03:21 squashfs-tools-4.3-arm-2
-rw-r--r-- 1 root root 1205 Aug 13 03:21 sqlite-3.20.0-arm-1
-rw-r--r-- 1 root root 1562 Aug 13 03:20 seamonkey-solibs-2.48-arm-1
-rw-r--r-- 1 root root 364644 Aug 13 03:20 seamonkey-2.48-arm-1
-rw-r--r-- 1 root root 10244 Aug 13 03:15 poppler-0.57.0-arm-1
-rw-r--r-- 1 root root 5581 Aug 13 03:14 pango-1.40.9-arm-1
-rw-r--r-- 1 root root 11777 Aug 13 03:14 oprofile-1.1.0-arm-4
-rw-r--r-- 1 root root 51983 Aug 13 03:14 nmap-7.60-arm-1
-rw-r--r-- 1 root root 1607 Aug 13 03:13 mtd-utils-090817-arm-1
-rw-r--r-- 1 root root 60374 Aug 13 03:12 mozilla-firefox-52.3.0esr-arm-1
-rw-r--r-- 1 root root 1491 Aug 13 03:10 mkinitrd-1.4.11-arm-5
-rw-r--r-- 1 root root 5107 Aug 13 03:09 mesa-17.1.6-arm-1
-rw-r--r-- 1 root root 7206 Aug 13 03:09 libxslt-1.1.29-arm-2
-rw-r--r-- 1 root root 1424 Aug 13 03:09 libpng-1.6.31-arm-1
-rw-r--r-- 1 root root 3574 Aug 13 03:08 libdrm-2.4.82-arm-1
-rw-r--r-- 1 root root 81867 Aug 13 03:08 imagemagick-6.9.9_5-arm-1
-rw-r--r-- 1 root root 32429 Aug 13 03:07 httpd-2.4.27-arm-2
-rw-r--r-- 1 root root 82127 Aug 13 03:07 hplip-3.17.7-arm-1
-rw-r--r-- 1 root root 6420 Aug 13 03:06 harfbuzz-1.4.8-arm-1
-rw-r--r-- 1 root root 72165 Aug 13 03:06 gtk+3-3.22.18-arm-1
-rw-r--r-- 1 root root 1141 Aug 13 03:04 gptfdisk-1.0.3-arm-1
-rw-r--r-- 1 root root 8034 Aug 13 03:04 gparted-0.29.0-arm-1
-rw-r--r-- 1 root root 7216 Aug 13 03:04 gnupg2-2.1.22-arm-1
-rw-r--r-- 1 root root 4441 Aug 13 03:04 gnupg-1.4.22-arm-1
-rw-r--r-- 1 root root 992 Aug 13 03:03 glibc-profile-2.26-arm-1
-rw-r--r-- 1 root root 257522 Aug 13 03:02 glibc-i18n-2.26-arm-1
-rw-r--r-- 1 root root 24315 Aug 13 03:00 glibc-2.26-arm-1
-rw-r--r-- 1 root root 1518 Aug 13 02:59 glew-2.1.0-arm-1
-rw-r--r-- 1 root root 17301 Aug 13 02:58 gdk-pixbuf2-2.36.8-arm-1
-rw-r--r-- 1 root root 2227 Aug 13 02:57 gcc-objc-7.1.0-arm-2
-rw-r--r-- 1 root root 11808 Aug 13 02:57 gcc-go-7.1.0-arm-2
-rw-r--r-- 1 root root 133943 Aug 13 02:55 gcc-gnat-7.1.0-arm-2
-rw-r--r-- 1 root root 2399 Aug 13 02:54 gcc-gfortran-7.1.0-arm-2
-rw-r--r-- 1 root root 42670 Aug 13 02:53 gcc-g++-7.1.0-arm-2
-rw-r--r-- 1 root root 43184 Aug 13 02:52 gcc-7.1.0-arm-2
-rw-r--r-- 1 root root 5207 Aug 13 02:51 e2fsprogs-1.43.5-arm-1
-rw-r--r-- 1 root root 1826 Aug 13 02:51 dhcp-4.3.6-arm-1
-rw-r--r-- 1 root root 4063 Aug 13 02:50 dbus-1.10.22-arm-1
-rw-r--r-- 1 root root 20710 Aug 13 02:50 curl-7.55.0-arm-1
-rw-r--r-- 1 root root 2504 Aug 13 02:50 btrfs-progs-4.12-arm-1
-rw-r--r-- 1 root root 10368 Aug 13 02:49 binutils-2.29-arm-2
-rw-r--r-- 1 root root 13300 Aug 13 02:48 bind-9.11.2-arm-1
-rw-r--r-- 1 root root 7927 Aug 13 02:47 glibc-solibs-2.26-arm-1
-rw-r--r-- 1 root root 3434 Aug 13 02:45 slackpkg-2.82.1-noarch-4
-rw-r--r-- 1 root root 1501 Jul 29 04:11 xlockmore-5.54-arm-2
-rw-r--r-- 1 root root 10169 Jul 29 04:11 xine-lib-1.2.8-arm-3
...etc

jimtabor · 08-24-2017, 06:43 AM

Hello,

Under the impression that -Current is compiled for hard float.
,
James

drmozes · 08-24-2017, 07:36 AM

Quote:

Originally Posted by abga

I was about to finalize a compilation how-to for FFMPEG last evening and by "testing before publishing" my instructions I've noticed that the compiler on both Slack 14.2 SF and Slack ARM current HF are producing inconsistent results. I've performed my last update on both systems around 13-18 Aug 2017 and noticed that glibc was updated.

Here are the findings:
On a pi2B (armv7) running SlackARM-current-HF by trying to produce armv6 SF code:
uname -a
Linux Goofy 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l BCM2709 GNU/Linux
x264# ./configure --enable-shared --disable-win32thread --enable-strip --extra-cflags='-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft'
No working C compiler found.

Please re-read what I posted on the 'hard float' thread.
You cannot build soft float output on -current - not using the supplied toolchain.

Quote:

Linux JunkPi 4.4.50+ #970 Mon Feb 20 19:12:50 GMT 2017 armv6l BCM2708 GNU/Linux
x264# ./configure --enable-shared --disable-win32thread --enable-strip --extra-cflags='-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft'

The result:
readelf -A libx264.so.152
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"

Again, this has been explained but I will explain one final time:

This is on 14.2:

Code:

root@zaden-142:~/ac/source/x/mesa/test# cc -o /tmp/out -march=armv6 t.c
root@zaden-142:~/ac/source/x/mesa/test# readelf -A /tmp/out
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6

Works because the OS is forwards compatible.

Code:

root@zaden-142:~/ac/source/x/mesa/test# cc -o /tmp/out -march=armv4t t.c
root@zaden-142:~/ac/source/x/mesa/test# readelf -A /tmp/out
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "5TE"
  Tag_CPU_arch: v5TE

That doesn't build for armv4t because the OS is built for a minimum of armv5te.

Quote:

I've also noticed that on the pi0 - SlackARM 14.2 SF when compiling without any CFLAGS options I get armv8 code with NEON FP code:
....
gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -mcpu=cortex-a8 -mfpu=neon
....

Cortex-a8 is ARMv8.

I don't know why you say you see a difference, but you're still confused about this so I'd spend time figuring that out first.

abga · 08-24-2017, 01:18 PM

@drmozes

Thanks for catching up on this. I was reporting an apparent bug and you shouldn't have been wasting time explaining what you already did in the other thread.

Quote:

Please re-read what I posted on the 'hard float' thread.
You cannot build soft float output on -current - not using the supplied toolchain.

Actually I could, before the 13-18 Aug 2017 updates and it was VERY helpful. I compiled the entire ffmpeg dependencies, Kodi dependencies and Kodi itself, 3 hours and 140MB worth of binaries on a Pi2B running SlackARM-current HF with the compiler flags -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft
I moved and use those binaries on my Pi0 running Slack 14.2 official - SoftFloat.
readelf -A /usr/lib/kodi/kodi.bin
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6ZK"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
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_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
Tag_Virtualization_use: TrustZone
You shouldn't worry anymore about this - I have an older not-upgraded backup of my running Slack 14.2 current HardFloat and I will load that on a spare Pi2B board in order to compile for the Pi0 armv6. That's until I get some time and build my own multilib toolchain. Carry on with your important work.

What got me scared was the fact that I couldn't compile on my Pi0 Slack 14.2 official - SoftFloat with the compiler flags -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft anymore. I got armv7 and NEON fpu code while using these compiler flags and without them, even by leaving the shell (resetting the environmental variables - $CFLAGS was empty) I got armv8 with neon fpu code generated, like something remained persistent / messed up in the compiler environment after the first try with -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft

It is still not working now:
echo $CFLAGS
-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft
...
gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -I/usr/local/include -I/usr/local/include -fomit-frame-pointer -fno-tree-vectorize -c -o common/mc.o common/mc.c
...
result:
readelf -A x264
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_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

By looking at the default compiler flags with gcc -Q --help=target I could find the following:
- on Slack 14.2 ARM - current- HardFloat
-mfloat-abi= hard
-mfp16-format= none
-mfpu= auto

- and on Slack ARM 14.2 - official - SoftFloat - is -mfpu=vfp right?
-mfloat-abi= soft
-mfp16-format= none
-mfpu= vfp

abga · 08-24-2017, 02:33 PM

@drmozes

It's the configure (updated recently) script from x264 that is totally messed up, sorry for all the trouble. It's not a compiler bug!

I just rebooted my pi0 running SlackARM 14.2 SoftFloat and replicated the issue in a clean environment:

root@JunkPi:/kit# git clone git://git.videolan.org/x264
Cloning into 'x264'...
remote: Counting objects: 20569, done.
remote: Compressing objects: 100% (4266/4266), done.
remote: Total 20569 (delta 17004), reused 19712 (delta 16260)
Receiving objects: 100% (20569/20569), 4.84 MiB | 932.00 KiB/s, done.
Resolving deltas: 100% (17004/17004), done.
root@JunkPi:/kit# cd x264/
root@JunkPi:/kit/x264# ./configure
platform: ARM
byte order: little-endian
system: LINUX
cli: yes
libx264: internal
shared: no
static: no
asm: yes
interlaced: yes
avs: avxsynth
lavf: yes
ffms: no
mp4: no
gpl: yes
thread: posix
opencl: yes
filters: resize crop select_every
lto: no
debug: no
gprof: no
strip: no
PIC: no
bit depth: 8
chroma format: all

You can run 'make' or 'make fprofiled' now.
root@JunkPi:/kit/x264# make V=1
cat common/opencl/x264-cl.h common/opencl/motionsearch.cl common/opencl/subpel.cl common/opencl/intra.cl common/opencl/weightp.cl common/opencl/downscale.cl common/opencl/bidir.cl | ./tools/cltostr.sh common/oclobj.h
dependency file generation...
gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -mcpu=cortex-a8 -mfpu=neon -I/usr/local/include -I/usr/local/include -fomit-frame-pointer -fno-tree-vectorize -c -o x264.o x264.c
gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -mcpu=cortex-a8 -mfpu=neon -I/usr/local/include -I/usr/local/include -fomit-frame-pointer -fno-tree-vectorize -c -o input/input.o input/input.c
gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -mcpu=cortex-a8 -mfpu=neon -I/usr/local/include -I/usr/local/include -fomit-frame-pointer -fno-tree-vectorize -c -o input/timecode.o input/timecode.c

In order to make sure it's the x264 configure script faulty, I just recompiled libmpeg2 on my pi0 running SlackARM 14.2 SoftFloat with:
export CFLAGS="$CFLAGS -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft"

and the result is consistent:

readelf -A libmpeg2.so.0.1.0
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6ZK"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
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_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

Sorry again for wasting your time, I'll let the devs at x264 know about their issues.

abga · 08-24-2017, 07:59 PM

I just wanted to apologize again. I figured out that I was actually compiling stuff for the Pi0 on the Pi2B by running Slackware ARM14.2 SoftFloat and NOT Slackware ARM - current HardFloat. I have 4 16GB SD Cards on my desk with different Slackware ARM images and just now realized that I have used the one with the Slackware ARM 14.2 SoftFloat on it (there are two identical).

drmozes is right - always was - Slackware ARM - current HardFloat IS NOT ABLE to produce armv6 SoftFloat code.

I wish I could remove this whole thread, the original issue was the configure script for X264 libs and has nothing to do with the compilers...

Exaga · 08-26-2017, 12:53 PM

Quote:

Originally Posted by abga

drmozes is right - always was

It's personally embarrassing to recount the number of occasions I've said, or thought, exactly the same thing.

Quote:

Originally Posted by abga

Slackware ARM - current HardFloat IS NOT ABLE to produce armv6 SoftFloat code.

hehehe

abga · 08-26-2017, 05:29 PM

@Exaga

While still a little bit on-topic (compilers related), thanks for your cross-compiler & kernel compilation how-to for RaspberryPi - I was studying it and considering to use it for creating an armv6 softfp/hard enabled compiler, but realized that you were working on armv7 HardFloat and you have produced a compiler without multilib support:
https://docs.slackware.com/howtos:ha...cross-compiler

- on drmozes ARM wisdom:
I really appreciate him for keeping his head up in this ARM architectures & compiler restrictions mess and helping with my arm-inexperienced noob questions.
As for me and the complications that led to this thread: I have 2 Pi2B and a Pi0 boards on my desk and I'm switching 4 SDCards between them by studying/learning how to build my own Slackware armv6 HardFloat port. I took now a permanent marker and wrote SF HF on the SDCards and changed the hostnames-SF/HF on those images accordingly

Besides, by looking at the build scripts I've learned now that it was his choice (maintenance simplicity, portability) to have only two maintained binary "flavors" - armv5te SoftFloat and armv7 HardFloat. Whereas my needs are somewhere in between - armv6 HardFloat

The glibc SlackBuild is even "hardcoded" to build only for armv7 HardFloat
http://slackware.uk/slackwarearm/sla...ibc.SlackBuild

AlienBob had a different, more flexible approach:
https://alien.slackbook.org/blog/armport/
- but he didn't maintain his work and I didn't follow his instructions because I wasn't sure those scripts will still work with the way Stuart organized the distro source code - an overlay-framework with patches over the slackware64-current sources.

However, I managed to start the compilation (it's compiling on a Pi2B Slack 14.2 ARM SoftFloat as I'm writing now) by following this guide in order to get an "armv6 softfp ready" compiler that could produce armv6 HardFloat code:
https://mindplusplus.wordpress.com/2...-raspberry-pi/
I'll document the changes (there are some) that are required to make that How-To work, once I'm done and confident that the compilation results are consistent.

Exaga · 08-27-2017, 12:09 PM

Quote:

Originally Posted by abga

@Exaga

While still a little bit on-topic (compilers related), thanks for your cross-compiler & kernel compilation how-to for RaspberryPi - I was studying it and considering to use it for creating an armv6 softfp/hard enabled compiler, but realized that you were working on armv7 HardFloat and you have produced a compiler without multilib support:
https://docs.slackware.com/howtos:ha...cross-compiler

The reason why I shared that cross-compiler project on Slack Docs was an attempt to generate interest in a Slackware ARM64 port. It's in no way comprehensive, or complete, and that is very much intentional.

It might be beneficial for you to have a read of the GCC configuration options. You may find the --enable-multilib option particularly interesting.

abga · 08-28-2017, 08:23 PM

Quote:

The reason why I shared that cross-compiler project on Slack Docs was an attempt to generate interest in a Slackware ARM64 port. It's in no way comprehensive, or complete, and that is very much intentional.

Actually you've done more than that and I'm again thankful for your effort. It's from that How-To I learned that in order to build a cross-compiler / or a multilib-compiler on the same architecture, you'll need to address the the binutils - gcc - glibc triplet. I might be using your shared knowledge to build a cross-compiler of my own.

Since you're interested in 64bit kernel/binaries on ARM (Raspberry Pi), you might find this long thread informative:
https://www.raspberrypi.org/forums/v...?f=63&t=152471

There doesn't seem to be a performance improvement 32/64 on these low memory Pi devices and the only interesting thing I read is that you cannot access the hardware accelerated AES crypto engine without a 64bit kernel...

drmozes · 08-29-2017, 01:36 AM

Quote:

Originally Posted by abga

- on drmozes ARM wisdom:
I really appreciate him for keeping his head up in this ARM architectures & compiler restrictions mess and helping with my arm-inexperienced noob questions.

No problems - happy to have the discussion.

Quote:

Originally Posted by abga

Besides, by looking at the build scripts I've learned now that it was his choice (maintenance simplicity, portability) to have only two maintained binary "flavors" - armv5te SoftFloat and armv7 HardFloat.

It's more prosaic than that. Upstream major projects stopped supporting older ARM CPUs some time ago, and as such, the writing on the wall for the future for a soft float port was clear. The port was taking too much time as well, so I abandoned it for a while until I wrote some more scripts to automate the packaging and building.
14.2 is still maintained, but the soft float port is not developed. I'll probably kill 14.2 at some point in the future, making maintained Slackware ARM releases hardware floating point only.

Quote:

Whereas my needs are somewhere in between - armv6 HardFloat

The glibc SlackBuild is even "hardcoded" to build only for armv7 HardFloat
http://slackware.uk/slackwarearm/sla...ibc.SlackBuild

Ah! thanks for the reminder. What you're seeing there is a script that was written at a time when I was focused on getting the hard float port bootstrapped, rather than try and make the script inherit and modify the toolchain flags from the slackkit configuration.
I've just changed glibc.SlackBuild to :
arm|aarch64) SLKCFLAGS="${SLKCFLAGS/-O2/-O3} -pipe -fPIC -fno-strict-aliasing"
There are a few others that could be updated - I'll do them as and when I come across them.

The build scripts in -current mostly have all of the toolchain flags abstracted in to the slackkit config file, and are being modified to set the arch quadlet in a variable, so that the ground work is there if I ever fancy doing a 64bit port.

Quote:

AlienBob had a different, more flexible approach:
https://alien.slackbook.org/blog/armport/
- but he didn't maintain his work and I didn't follow his instructions because I wasn't sure those scripts will still work with the way Stuart organized the distro source code - an overlay-framework with patches over the slackware64-current sources.

AlienBOB's approach was to duplicate the Slackware tree and modify the build scripts and (IIRC) get the changes merged upstream.
Some of those changes did make it, and you'll also see 'arm' in most of the x86 SlackBuild scripts but these are from the ARMedslack 13.37 and prior releases. The issue is that Slackware does not use a source control repo, so nobody but Patrick can edit it.
Whenever any of us want to change anything, we modify the scripts/package dir and upload it to the server and Patrick takes it if/when he wants to.
A port cannot be maintained like that unless you want to spend fruitless hours moving source files around. I tried doing that and it lasted a couple of weeks until I came up with the overlay system.

You'll find this yourself, since I don't think you've realised it yet - but you're going to have to rebuild the *entire* OS (or just enough to fulfill your needs -- because as I've told you, you cannot mix hardware floating point ABI with a soft float ABI user land).
Fortunately the ARM tree was built from the ground up with the grand idea of supporting ARM and other architectures that I was going to port (haha), so generally it's far more flexible; it just (I guess) appears more cumbersome since there's a high degree of abstraction in comparison to the atomic nature of the x86 source tree.

When I was boostrapping the hard float port, I decided to use AlienBOB's work as a base. However, I quickly discovered that his binaries ran on the soft float port. AlienBOB's port is actually using the soft float ABI, but is built for armv7 and uses NEON instructions - so I could not use it as I needed an OS that used the hard float ABI.
You could do the same as he did - build on 14.2 using the soft float ABI and set your CFLAGS to armv6. I don't know if there'll be any fallout from that though.
However, I admit that at this point, my knowledge enters a state of disarray. I don't see how the mix of compiling to use the NEON instruction set yet still using the soft float ABI means that you'd get to use those hard float instructions.

abga · 08-29-2017, 01:22 PM

Quote:

No problems - happy to have the discussion.

I hope so, it's also a pleasure on my side. It's also educative for the rest of the community. Please let me know if I'm too insistent and taking too much of your important time, I'll conform. Well, I'll try

Quote:

14.2 is still maintained, but the soft float port is not developed. I'll probably kill 14.2 at some point in the future, making maintained Slackware ARM releases hardware floating point only.

I'm aware of that and you shouldn't care about the armv6 arch that much, it's already obsolete and apart from the Raspberry Foundation, presumably selling Broadcom's armv6 BCM2835 overproduction in the form of Pi Zero, there are no new devices sold with this architecture on the market.

Quote:

The build scripts in -current mostly have all of the toolchain flags abstracted in to the slackkit config file, and are being modified to set the arch quadlet in a variable, so that the ground work is there if I ever fancy doing a 64bit port.

Happy to hear that, it'll sure simplify my work. Besides, I'm not sure I was right in assessing AlienBob's ARM work as "flexible" or centralized. By looking at his scripts I thought he has centralized the architecture CFLAGS in only one file:
http://taper.alienbase.nl/mirrors/al...d_machine.conf
But then, by browsing the SlackBuilds from Slack ARM - current, I got some hardcoded armv7 CFLAGS and your name was not to be found in the header section, but only his. Nevertheless, I'll use your updated SlackBuilds from SlackARM - current.

Quote:

You'll find this yourself, since I don't think you've realised it yet - but you're going to have to rebuild the *entire* OS (or just enough to fulfill your needs -- because as I've told you, you cannot mix hardware floating point ABI with a soft float ABI user land).

Oh, I did! And it scared me!

I'm totally inexperienced in this and just learning now. Actually, by using Slack on x86 for almost 2 decades, I only recompiled (optimized) the kernel (that's only until I reached Intel's multicore architecture and its internal advanced branch-prediction&co, after which it was useless to recompile) and my own services in the "parallel world" /usr/local userland space, and never touched the "all holly" compiler or even trying to understand how to bootstrap/build the whole Slack.

Quote:

Fortunately the ARM tree was built from the ground up with the grand idea of supporting ARM and other architectures that I was going to port (haha), so generally it's far more flexible; it just (I guess) appears more cumbersome since there's a high degree of abstraction in comparison to the atomic nature of the x86 source tree.

Actually, I'd propose to consider such a flexible approach for the future development of Slack ARM. I'm surely you're aware that the ARM architecture is pretty simplistic (compared to x86), efficient too - power consumption, and you don't have the CPU to do much execution code optimization in its cache/buffers/piplines/branch prediction. This optimization should be done by the compiler while building the binaries and this is why you might need to produce already optimized code - thus, having multiple Slack ARM flavors. But that's what Gentoo is doing, isn't it

Quote:

However, I admit that at this point, my knowledge enters a state of disarray.

You're not the only one, please don't feel lonely

At least you have vast experience with bootstrapping / building the OS!

On the NEON SIMD instructions I might have a "profound" question, but I'll address it in another thread.

We should move from this thread - I've opened another one specific with my armv6 "struggles".