Re: [Buildroot] [PATCH 2/2] package/rpi-userland: package is deprecated

["Gaël PORTAY" <gael.portay@gmail.com>]

Hello Thomas,

On Thu Jul 25, 2024 at 4:59 PM CEST, Thomas Petazzoni wrote:
> I did a bit of experiment, but could not come to a conclusion. ldrh is
> definitely recognized, but not ldrhcs. And building in Thumb mode
> doesn't make any difference:
>
> thomas@windsurf:/tmp$ cat plop.S 
> ldrhcs r0, [ip], #2
>
> thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv6zk -c plop.S 
> plop.S: Assembler messages:
> plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2'
>
> thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv6zk -mthumb -c plop.S 
> plop.S: Assembler messages:
> plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2'
>
> thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv8-a -mthumb -c plop.S plop.S: Assembler messages:
> plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2'
>
> thomas@windsurf:/tmp$ arm-linux-gnu-gcc -march=armv8-a -c plop.S 
> plop.S: Assembler messages:
> plop.S:1: Error: bad instruction `ldrhcs r0,[ip],#2'
>

Oh, it appears I conclude to something inexact too fast.

The vp8.o is compiled with the following command:

	/home/gportay/src/buildroot/output/host/bin/arm-buildroot-linux-gnueabihf-gcc -MMD -MF obj/third_party/ffmpeg/ffmpeg_internal/vp8.o.d -DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DFFMPEG_CONFIGURATION=NULL -DCHROMIUM_NO_LOGGING -D_ISOC99_SOURCE -D_LARGEFILE_SOURCE -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DCR_SYSROOT_HASH=c2e54f675b83a61301dcdb22e8e7a2b85c01d58c -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../3rdparty/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/arm  -I../../3rdparty/chromium/third_party/ffmpeg -I../../3rdparty/chromium/third_party/ffmpeg/compat/atomics/gcc -Igen -I../../3rdparty/chromium -Igen -fPIC -Wno-deprecated-declarations -fomit-frame-pointer -w -std=c99 -pthread -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -marm -g0 -fvisibility=hidden -Wno-psabi -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -I/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/opus -std=gnu11 --sysroot=/home/gportay/src/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot -c ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/vp8.c -o obj/third_party/ffmpeg/ffmpeg_internal/vp8.o

The compiler flag -marm is set; and if the -mthumb is used instead, the
assembler errors gone and the Elf object is assembled.

That is why I assumed badly the instruction is taken from the Thumb
instruction set. Then I googled for ldrh (without the syntax fields
c/e) + Thumb, I open the first response without reading too much and
I closed the tab right after.

ARM has introduced the Unified Assembler Language (since armv6t2 IIRC?),
allowing mixing A32 and T32 instructions (ARM32 and Thumb32; not using
the old Thumb 16-bit instructions).

This is certainly why ffmpeg have the two options --enable-armv6 and
--enable-armv6t2, and why the hardcoded configs in the bundled ffmpeg
enables both for arm[1] and arm-neon[2].

Better to reread:

	https://developer.arm.com/documentation/ddi0406/cb/Appendixes/ARMv6-Differences/Instruction-set-support

> > Note: chromium fails at configure if -feature-webengine-arm-thumb is
> > forced to its command-line instead of failing afterward at build; so it
> > is interresting to enforce it if CPU supports Thumb.
>
> Not sure to understand this part.
>

It the configure flag -feature-webengine-arm-thumb is forced at
configure, the configure script fails with the error below because the
condition is unmet[3]:

	WARNING: Thumb instruction set is required to build ffmpeg for QtWebEngine.

	ERROR: Feature 'webengine-arm-thumb' was enabled, but the pre-condition 'config.linux && arch.arm && tests.webengine-arm-thumb' failed.

Otherwise, the build fails at compilation with the issue we are talking
about.

> > Also, it is wrong for raspberry pi 1 (armv6).
> > 
> > The second raises at linking blink:
> > 
> > 	/home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: warning: /home/gportay/src/buildroot/output/build/qt5webengine-5.15.14/src/core/release/obj/third_party/blink/renderer/platform/heap/asm/asm/SaveRegisters_arm.o: missing .note.GNU-stack section implies executable stack
> > 	/home/gportay/src/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/13.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
> > 	collect2: error: ld returned 1 exit status
> > 
> > Is that possible this is the issue you mentioned?
>
> This is the issue I mentioned indeed. The linker bails out with a
> non-zero error code, but does not show any error message.
>

Nice, I have sent a patch and added you in CC; see:

	https://patchwork.ozlabs.org/project/buildroot/patch/20240731110813.17489-1-gael.portay@rtone.fr/

I need the help of generate ninja warriors for it.

> > Also, I have noticed that chromium checks for jpeg-turbo specific
> > symbols if -feature-webengine-system-jpeg; raspberrypi uses libjpeg as
> > jpeg-turbo cannot be built for this target, and qt5webengine fails at
> > configure.
>
> Dang, I am pretty sure I saw this, switched to jpeg-turbo, but I forgot
> to include it in my patch series. How come jpeg-turbo cannot be built
> for your target? As far as I can see, jpeg-turbo does not have any
> architecture dependency. Are you sure you didn't misread
> package/jpeg/Config.in? It uses jpeg-turbo as default if
> BR2_PACKAGE_JPEG_SIMD_SUPPORT, but it does not prevent from selecting
> jpeg-turbo if BR2_PACKAGE_JPEG_SIMD_SUPPORT is not true.
>

Oh right, the choice is based on BR2_PACKAGE_JPEG_SIMD_SUPPORT that
requires BR2_ARM_CPU_HAS_NEON (not available on armv6).

> Best regards,
>
> Thomas

Regards,
Gaël

[1]: https://github.com/qt/qtwebengine-chromium/blob/87-based/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/arm/config.h
[2]: https://github.com/qt/qtwebengine-chromium/blob/87-based/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/arm-neon/config.h
[3]: https://github.com/qt/qtwebengine/blob/v5.15.14-lts/src/buildtools/configure.json#L709-L713
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot