retroarch returns "illegal instruction"

[gzuh]

I ran:
sudo apt install retroarch

which installed just fine, but upon running, it returns illegal instruction.
This is on a Raspberry Pi Zero W.

I believe this package may include arm7 code but I was allowed to get it with my Zero.

Linux bmo 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

[gzuh (geezuh)]

   +------------------------------------------------------------------------------------------------------------------------------------+
  >|0x42ad90 vmov.i32 d16, #0 ; 0x00000000 |
   |0x42ad94 str r2, [r1, #8] |
   |0x42ad98 str r2, [r1, #12] |
   |0x42ad9c str r2, [r3, #2000] ; 0x7d0 |
   |0x42ada0 str r2, [r3, #-2120] ; 0xfffff7b8 |
   |0x42ada4 mov r12, #1 |
   |0x42ada8 vstr d16, [r0, #-8] |
   |0x42adac b 0x42a54c |
   |0x42adb0 add r7, r7, #12288 ; 0x3000 |
   |0x42adb4 add r4, sp, #8 |
   |0x42adb8 ldrb r3, [r7, #356] ; 0x164 |
   |0x42adbc mov r1, #0 |
   |0x42adc0 mov r0, #1 |
   |0x42adc4 strb r3, [r4, #-5]! |
   |0x42adc8 bl 0x42df90 |
   |0x42adcc mov r1, r4 |
   |0x42add0 mov r0, #2 |
   |0x42add4 bl 0x42df90 |
   |0x42add8 mov r12, #1 |
   |0x42addc b 0x42a54c |
   |0x42ade0 ldr r3, [pc, #1184] ; 0x42b288 |
   |0x42ade4 add r3, pc, r3 |
   +------------------...

[gzuh (geezuh)]

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  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_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

[Alistair Buxton (a-j-buxton)]

I'm not OP but I looked in to this with OP on IRC :)

Previous comments are the output from gdb "layout asm" after retroarch crashed with SIGILL, and readelf -A /usr/bin/retroarch

These caught my eye:

  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1

VFPv3 there seems wrong? It's the only binary on my system tagged like that, all others are VFPv2.

But I don't know the instruction set well enough to know if it is crashing on a VFPv3 instruction.

[peter green (plugwash)]

vmov is determinately a vfp instruction.

The instruction itself is fine on vfpv2 but the register number used is not. VFPv2 only has registers D0 to D15.

Can you do

apt-cache policy retroarch

so that we can confirm you are using a package from the raspbian repos and not one from somewhere else?

[gzuh (geezuh)]

retroarch:
  Installed: 1.3.6+dfsg1-1
  Candidate: 1.3.6+dfsg1-1
  Version table:
 *** 1.3.6+dfsg1-1 500
        500 http://mirrordirector.raspbian.org/raspbian stretch/main
armhf Packages
        100 /var/lib/dpkg/status

On Mon, Nov 27, 2017 at 6:35 AM, peter green <email address hidden> wrote:

> vmov is determinately a vfp instruction.
>
> The instruction itself is fine on vfpv2 but the register number used is
> not. VFPv2 only has registers D0 to D15.
>
> Can you do
>
> apt-cache policy retroarch
>
> so that we can confirm you are using a package from the raspbian repos
> and not one from somewhere else?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1734592
>
> Title:
> retroarch returns "illegal instruction"
>
> Status in Raspbian:
> New
>
> Bug description:
> I ran:
> sudo apt install retroarch
>
> which installed just fine, but upon running, it returns illegal
> instruction.
> This is on a Raspberry Pi Zero W.
>
> I believe this package may include arm7 code but I was allowed to get
> it with my Zero.
>
> Linux bmo 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/raspbian/+bug/1734592/+subscriptions
>

[gzuh (geezuh)]

retroarch:
  Installed: 1.3.6+dfsg1-1
  Candidate: 1.3.6+dfsg1-1
  Version table:
 *** 1.3.6+dfsg1-1 500
        500 http://mirrordirector.raspbian.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status

[Alistair Buxton (a-j-buxton)]

Possibly due to this --enable-neon in debian/rules?

else ifeq ($(ARCH),armhf)
        CONFIG_EXTRA_FLAGS=--disable-vg --disable-cg --enable-gles --enable-neon --enable-floathard

[peter green (plugwash)]

I just had a chat with the retroarch guys on IRC, unfortunately it seems they do not have a mailling list.

<plugwash> Hi guys, I am the maintainer of Raspbian, recently a bug report regarding retroarch in Raspbian dropped in and I could do with some advice.
<orbea> plugwash: what is the bug report?
<plugwash> https://bugs.launchpad.net/bugs/1734592
<retrobot> Title: Bug #1734592 “retroarch returns “illegal instruction"" : Bugs : Raspbian
<orbea> plugwash: this is 1.3.6?
<hunterk> ah, yeah, could be related to the NEON flag
<plugwash> orbea, yes
<plugwash> So my questions
<orbea> plugwash: any way you can update it and see if it still occurs?
<orbea> 1.3.6 is kind of old :)
<orbea> 1.6.9 just came out recently
<orbea> i mean there is not much point in fixing something that might already be fixed? :)
<hunterk> I know debian likes to use super-old packages, which is fine, but seeing if it's already fixed would indeed keep us from reinventintating the wheel
<plugwash> So anyway my questions
<plugwash> 1. Is there an easy way to tell the retroarch build system not to hide the commands it is running
<plugwash> 2. Is retroarch supposed to support runtime detection of neon?
<orbea> yes, but gimme me a moment to remember exactly how
<hunterk> I don't think we do runtime NEON detection, no
<orbea> plugwash: ./configure && make V=1
* ashark has quit (Ping timeout: 240 seconds)
<orbea> pretty sure that existed even in 1.3.6
* seventh has quit (Ping timeout: 250 seconds)
<plugwash> hunterk, thanks for the info, that kinda sucks from the point of view of raspbian since our users are split between neon and non-neon systems
<orbea> plugwash: for neon you need ./configure --enable-neon
<orbea> its set to off by default
<orbea> i can see why that would be problematic..
* Twinaphex has quit (Read error: Connection reset by peer)
<orbea> hacky solution would to ship RetroArch and RetroArch-neon
<plugwash> orbea, right but it's turned on in the Debian packaging (which we have picked up in raspbian). That was why I was trying to find out if retroarch had runtime detection or if "--enable-neon" was intentionally incompatible with non-neon systems.
<orbea> im not sure runtime detection would be ideal either...some distros ship neon regardless if its arm or not
<orbea> see slackware
* ashark (~[e-mail]) has joined
<plugwash> umm neon is an arm extension, neon on non-arm doesn't make sense as a concept.
<orbea> it does if you ship a full install which may or may not be arm
<orbea> package management is pretty different for debian and slackware :P
<hunterk> so what would be a solution? raspbian uses the same package for all hardware?
<orbea> split it into two packages is the easiest I can think of
<orbea> retroarch and retroarch-neon
<hunterk> assuming they only have a single repo

I have built a retroarch package (In a raspbian stretch environment) without neon and would like people to test it.

http://plugwash.raspbian.org/retroarchnoneon/

If it works we can then think about where we go from here.

[gzuh (geezuh)]

The new package returns the following error on my machine:

pi@bmo:~/src $ retroarch
retroarch: symbol lookup error: retroarch: undefined symbol: vgImageSubData

On Thu, Nov 30, 2017 at 1:49 PM, peter green <email address hidden> wrote:

> I just had a chat with the retroarch guys on IRC, unfortunately it seems
> they do not have a mailling list.
>
> <plugwash> Hi guys, I am the maintainer of Raspbian, recently a bug report
> regarding retroarch in Raspbian dropped in and I could do with some advice.
> <orbea> plugwash: what is the bug report?
> <plugwash> https://bugs.launchpad.net/bugs/1734592
> <retrobot> Title: Bug #1734592 “retroarch returns “illegal instruction"" :
> Bugs : Raspbian
> <orbea> plugwash: this is 1.3.6?
> <hunterk> ah, yeah, could be related to the NEON flag
> <plugwash> orbea, yes
> <plugwash> So my questions
> <orbea> plugwash: any way you can update it and see if it still occurs?
> <orbea> 1.3.6 is kind of old :)
> <orbea> 1.6.9 just came out recently
> <orbea> i mean there is not much point in fixing something that might
> already be fixed? :)
> <hunterk> I know debian likes to use super-old packages, which is fine,
> but seeing if it's already fixed would indeed keep us from reinventintating
> the wheel
> <plugwash> So anyway my questions
> <plugwash> 1. Is there an easy way to tell the retroarch build system not
> to hide the commands it is running
> <plugwash> 2. Is retroarch supposed to support runtime detection of neon?
> <orbea> yes, but gimme me a moment to remember exactly how
> <hunterk> I don't think we do runtime NEON detection, no
> <orbea> plugwash: ./configure && make V=1
> * ashark has quit (Ping timeout: 240 seconds)
> <orbea> pretty sure that existed even in 1.3.6
> * seventh has quit (Ping timeout: 250 seconds)
> <plugwash> hunterk, thanks for the info, that kinda sucks from the point
> of view of raspbian since our users are split between neon and non-neon
> systems
> <orbea> plugwash: for neon you need ./configure --enable-neon
> <orbea> its set to off by default
> <orbea> i can see why that would be problematic..
> * Twinaphex has quit (Read error: Connection reset by peer)
> <orbea> hacky solution would to ship RetroArch and RetroArch-neon
> <plugwash> orbea, right but it's turned on in the Debian packaging (which
> we have picked up in raspbian). That was why I was trying to find out if
> retroarch had runtime detection or if "--enable-neon" was intentionally
> incompatible with non-neon systems.
> <orbea> im not sure runtime detection would be ideal either...some distros
> ship neon regardless if its arm or not
> <orbea> see slackware
> * ashark (~[e-mail]) has joined
> <plugwash> umm neon is an arm extension, neon on non-arm doesn't make
> sense as a concept.
> <orbea> it does if you ship a full install which may or may not be arm
> <orbea> package management is pretty different for debian and slackware :P
> <hunterk> so what would be a solution? raspbian uses the same package for
> all hardware?
> <orbea> split it into two packages is the easiest I can think of
> <orbea> retroarch and retroarch-neon
> <hunterk> assuming they only have a single repo
>
> I have ...