On Tue, 16 Jul 2019 at 18:52, Gordan Bobic <gordan at 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 at 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 at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20190717/ec17deb6/attachment-0006.html>