[Arm-dev] Tracking Down "Illegal instruction" Sources

[Gordan Bobic]

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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20190716/731df9ef/attachment.html>