I'm trying to track down the executables/libraries that are behind the "Illegal instruction" errors I am seeing on my Tegra 2 devices. It seems a given that this is due to some packages from the GL stack (Mesa, libglvnd, etc.) having been build with assumptions of NEON always being present, but I'm trying to figure out a way to determine this definitively.
I have tried the approach along the lines of:
objdump -Ds $file | grep -E 'vadd.|vmul.'
since vadd and vmul are both NEON assembly instructions, but this seems to flag up nearly everything, most of which is in fact working (e.g. Firefox 52.x).
So either my approach is wrong or there are many binaries that do some kind of runtime detection and selectively use NEON if supported by the hardware.
The reason i am looking into this is because gdm doesn't work without working GL (even software mesa GL). It works on my Chromebook without hardware accelerated drivers, but doesn't work on my Tegra laptop without accelerated drivers. On the Chromebook (Exynos) glxgears runs (albeit slowly), but on Tegra, it crashes with "Illegal instruction".
I tried rebuilding libglvnd and mesa on the local machine in a hope that NEON capability is auto-detected but that doesn't seem to have made any difference.
Any advice/suggestions/insights gratefully received.
I started digging at /bin/glxgears, and tracking things down from there, looking at what libraries it is linked against, and the libraries those libraries are linked against. Here is what I found that objdump identifies as containing NEON instructions:
/bin/glxgears /lib/libc.so.6 /lib/libgcc_s.so.1 /lib/libX11.so.6 /lib/libxcb.so.1
I am very much hoping we can just ignore libc and libgcc - by explaining those away as containing runtime NEON detection to avoid executing NEON instructions. libX11 and libxcb - you'd think that if these were causing the problem
Further, these contain NEON instructions among the libGL* libraries, but they don't appear to be being linked against by glxgears: /lib/libGLU.so.1.3.1 /lib/libGLX_mesa.so.0.0.0 /lib/libGL.so.1.7.0
gdm which fails for similar reasons seems to be linked against the following additional libraries that contain NEON instructions:
libgio-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0 libxcb.so.1 libsystemd.so.0 libmount.so.1 libm.so.6 liblzma.so.5 liblz4.so.1 libgcrypt.so.11 libdw.so.1 libblkid.so.1 libfreebl3.so libelf.so.1 libbz2.so.1
So it looks like there is NEON all over the place. The question then becomes - how is anything working at all? Do libsystemd and libmount really have any justifiable reason for containing any runtime detection NEON accelerations? Surely if cannot be by pure blind luck that those NEON instructions are in functions that never seem to get invoked during regular use, can it?
On Sun, Jul 14, 2019 at 3:55 PM Gordan Bobic gordan@redsleeve.org wrote:
I'm trying to track down the executables/libraries that are behind the "Illegal instruction" errors I am seeing on my Tegra 2 devices. It seems a given that this is due to some packages from the GL stack (Mesa, libglvnd, etc.) having been build with assumptions of NEON always being present, but I'm trying to figure out a way to determine this definitively.
I have tried the approach along the lines of:
objdump -Ds $file | grep -E 'vadd.|vmul.'
since vadd and vmul are both NEON assembly instructions, but this seems to flag up nearly everything, most of which is in fact working (e.g. Firefox 52.x).
So either my approach is wrong or there are many binaries that do some kind of runtime detection and selectively use NEON if supported by the hardware.
The reason i am looking into this is because gdm doesn't work without working GL (even software mesa GL). It works on my Chromebook without hardware accelerated drivers, but doesn't work on my Tegra laptop without accelerated drivers. On the Chromebook (Exynos) glxgears runs (albeit slowly), but on Tegra, it crashes with "Illegal instruction".
I tried rebuilding libglvnd and mesa on the local machine in a hope that NEON capability is auto-detected but that doesn't seem to have made any difference.
Any advice/suggestions/insights gratefully received.
On Tue, 16 Jul 2019 at 18:52, Gordan Bobic gordan@redsleeve.org wrote:
I started digging at /bin/glxgears, and tracking things down from there, looking at what libraries it is linked against, and the libraries those libraries are linked against. Here is what I found that objdump identifies as containing NEON instructions:
/bin/glxgears /lib/libc.so.6 /lib/libgcc_s.so.1 /lib/libX11.so.6 /lib/libxcb.so.1
I am very much hoping we can just ignore libc and libgcc - by explaining those away as containing runtime NEON detection to avoid executing NEON instructions. libX11 and libxcb - you'd think that if these were causing the problem
Further, these contain NEON instructions among the libGL* libraries, but they don't appear to be being linked against by glxgears: /lib/libGLU.so.1.3.1 /lib/libGLX_mesa.so.0.0.0 /lib/libGL.so.1.7.0
gdm which fails for similar reasons seems to be linked against the following additional libraries that contain NEON instructions:
libgio-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0 libxcb.so.1 libsystemd.so.0 libmount.so.1 libm.so.6 liblzma.so.5 liblz4.so.1 libgcrypt.so.11 libdw.so.1 libblkid.so.1 libfreebl3.so libelf.so.1 libbz2.so.1
So it looks like there is NEON all over the place. The question then becomes - how is anything working at all? Do libsystemd and libmount really have any justifiable reason for containing any runtime detection NEON accelerations? Surely if cannot be by pure blind luck that those NEON instructions are in functions that never seem to get invoked during regular use, can it?
NEON accelerations are probably compiled in to speed up checksums and certain encryption routines. Doing a SHA512 and AES encryption/decryption may be much faster on the GPU than the CPU even with specific instructions... especially when you have to constantly do it for filesystems. There may also be some assembly instructions which 'do work' on most hardware even if they are listed as 'NEON'. Then there will be the subset which don't exist and you get the illegal instruction.
On Sun, Jul 14, 2019 at 3:55 PM Gordan Bobic gordan@redsleeve.org wrote:
I'm trying to track down the executables/libraries that are behind the "Illegal instruction" errors I am seeing on my Tegra 2 devices. It seems a given that this is due to some packages from the GL stack (Mesa, libglvnd, etc.) having been build with assumptions of NEON always being present, but I'm trying to figure out a way to determine this definitively.
I have tried the approach along the lines of:
objdump -Ds $file | grep -E 'vadd.|vmul.'
since vadd and vmul are both NEON assembly instructions, but this seems to flag up nearly everything, most of which is in fact working (e.g. Firefox 52.x).
So either my approach is wrong or there are many binaries that do some kind of runtime detection and selectively use NEON if supported by the hardware.
The reason i am looking into this is because gdm doesn't work without working GL (even software mesa GL). It works on my Chromebook without hardware accelerated drivers, but doesn't work on my Tegra laptop without accelerated drivers. On the Chromebook (Exynos) glxgears runs (albeit slowly), but on Tegra, it crashes with "Illegal instruction".
I tried rebuilding libglvnd and mesa on the local machine in a hope that NEON capability is auto-detected but that doesn't seem to have made any difference.
Any advice/suggestions/insights gratefully received.
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
In such situation, I would try to use GDB.
- gdb <application> and run the whole, till it crashes.
- gdb attached to a daemon, with option -p
- gdb on a core file, but might need to enable that, system wide.
My 2 cents.
Regards,
Stephan.
On 14-Jul-19 16:55, Gordan Bobic wrote:
I'm trying to track down the executables/libraries that are behind the "Illegal instruction" errors I am seeing on my Tegra 2 devices. It seems a given that this is due to some packages from the GL stack (Mesa, libglvnd, etc.) having been build with assumptions of NEON always being present, but I'm trying to figure out a way to determine this definitively.
I have tried the approach along the lines of:
objdump -Ds $file | grep -E 'vadd.|vmul.'
since vadd and vmul are both NEON assembly instructions, but this seems to flag up nearly everything, most of which is in fact working (e.g. Firefox 52.x).
So either my approach is wrong or there are many binaries that do some kind of runtime detection and selectively use NEON if supported by the hardware.
The reason i am looking into this is because gdm doesn't work without working GL (even software mesa GL). It works on my Chromebook without hardware accelerated drivers, but doesn't work on my Tegra laptop without accelerated drivers. On the Chromebook (Exynos) glxgears runs (albeit slowly), but on Tegra, it crashes with "Illegal instruction".
I tried rebuilding libglvnd and mesa on the local machine in a hope that NEON capability is auto-detected but that doesn't seem to have made any difference.
Any advice/suggestions/insights gratefully received.
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
-
Gordan Bobic -
Stephan GUILLOUX -
Stephen John Smoogen