swp on armv8 (Was: Haskell on arm needs help)
Joachim Breitner wrote: Hi, Am Mittwoch, den 03.12.2014, 23:02 +0100 schrieb Joachim Breitner: Trying to use it, but ghc fails to install in the schroot, and using just dd-schroot-cmd, I cannot debug this. Does installing ghc work properly for you? $ dd-schroot-cmd -c ghc apt-get install ghc Reading package lists... Building dependency tree... Reading state information... ghc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. 1 not fully installed or removed. Conf ghc (7.6.3-20 Debian:unstable [armhf]) Do it for real [Y/n]: Reading package lists... Building dependency tree... Reading state information... ghc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Download complete and in download only mode Reading package lists... Building dependency tree... Reading state information... ghc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up ghc (7.6.3-20) ... Illegal instruction Illegal instruction dpkg: error processing package ghc (--configure): subprocess installed post-installation script returned error exit status 132 Errors were encountered while processing: ghc E: Sub-process /usr/bin/dpkg returned an error code (1) Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew install -- ghc exited with exit code 1. there is more things strage with this machine. The above was the "sid" schroot (presuambly arm64). I think the default chroot arch follows the userland arch of the "outer system" and the outer system on asachi is armhf. I can confirm that on asachi ghc fails to install in the armhf chroot, installs but fails to run in the armel chroot and installs and runs in the arm64 chroot. On the armel chroot on that machine I can install ghc, but cannot run it successfully: ~/ghc-7.8.20141119 $ ghc Illegal instruction ~/ghc-7.8.20141119 $ ghc --version Illegal instruction (This is calling the ghc from the package from unstable.) I vaugely remember something a while back about some deprecated 32-bit arm instructions needing kernel emulation on armv8 and that emulation not being implemented yet. After some fighting with gdb I got (sid_armel-dchroot)plugwash@asachi:~$ gdb /usr/lib/ghc/lib/ghc <--snip gdb startup--> Reading symbols from /usr/lib/ghc/lib/ghc...(no debugging symbols found)...done. (gdb) run Starting program: /usr/lib/ghc/lib/ghc Cannot access memory at address 0x0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x02921958 in ?? () (gdb) <--snip fighting with gdb--> (gdb) disassemble 0x02921958,0x02921962 Dump of assembler code from 0x2921958 to 0x2921962: => 0x02921958: swp r3, r4, [r5] 0x0292195c: cmp r3, #0 0x02921960: beq 0x292197c End of assembler dump. (gdb) swp has been deprecated for a while, armhf binaries should really avoid using it but sadly other than runtime CPU detection i'm not sure there is much choice for armel. AIUI swp is already handled through kernel emulation on armv7 multiprocessor systems. There seem to be patches to port that emulation to arm64 but it doesn't appear they are in the kernel tree debian is using. Having 32-bit binaries break on armv8 systems due to lack of the swp instruction does not seem like a good thing so IMO we really want this in our kernels before release. Putting debian-arm back in cc and adding debian-kernel to cc to hopefully get some comments from people more knowlagable, Should I use a different machine to debug armel build failures? Or is ghc in unstable (and hence testing) that broken on armel? Theres a few armv7 porterboxes available though with lower resources than asachi abel.debian.org (I think this is the best resourced one) harris.debian.org ipa.debian.net (non-dsa) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f9b7d.6080...@p10link.net
Re: swp on armv8 (Was: Haskell on arm needs help)
On Wed, 2014-12-03 at 23:23 +, peter green wrote: > I vaugely remember something a while back about some deprecated 32-bit > arm instructions needing kernel emulation on armv8 and that emulation > not being implemented yet. That's correct, and IIRC swp is one of those instructions. > AIUI swp is already handled through kernel emulation on armv7 > multiprocessor systems. There seem to be patches to port that emulation > to arm64 but it doesn't appear they are in the kernel tree debian is > using. > Having 32-bit binaries break on armv8 systems due to lack of the > swp instruction does not seem like a good thing so IMO we really want > this in our kernels before release. If those patches have gone into a later upstream kernel than we have in Jessie (v3.16) then we should certainly backport them. IIRC they were controversial though, so if they haven't hit mainline I'd be *very* reluctant to "fork" the v8 userspace ABI. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417682318.2372.44.ca...@hellion.org.uk
Bug#771997: swp on armv8 (Was: Haskell on arm needs help)
Source: linux Version: 3.16.7-2 Severity: important X-Debbugs-CC: debian-...@lists.debian.org On Thu, 2014-12-04 at 08:38 +, Ian Campbell wrote: > On Wed, 2014-12-03 at 23:23 +, peter green wrote: > > > I vaugely remember something a while back about some deprecated 32-bit > > arm instructions needing kernel emulation on armv8 and that emulation > > not being implemented yet. > > That's correct, and IIRC swp is one of those instructions. > > > AIUI swp is already handled through kernel emulation on armv7 > > multiprocessor systems. There seem to be patches to port that emulation > > to arm64 but it doesn't appear they are in the kernel tree debian is > > using. > > Having 32-bit binaries break on armv8 systems due to lack of the > > swp instruction does not seem like a good thing so IMO we really want > > this in our kernels before release. > > If those patches have gone into a later upstream kernel than we have in > Jessie (v3.16) then we should certainly backport them. IIRC they were > controversial though, so if they haven't hit mainline I'd be *very* > reluctant to "fork" the v8 userspace ABI. They are in the arm64 maintainer's for-next/core branch but not in Linus' tree (yet): $ git log --oneline v3.16..origin/master -- arch/arm64/kernel/armv8_deprecated.c $ git log --oneline v3.16..arm64/for-next/core -- arch/arm64/kernel/armv8_deprecated.c 9096339 arm64: fix return code check when changing emulation handler d784e29 arm64: Trace emulation of AArch32 legacy instructions c852f32 arm64: Emulate CP15 Barrier instructions bd35a4a arm64: Port SWP/SWPB emulation support from arm 587064b arm64: Add framework for legacy instruction emulation I've bcc'd submit@ on this mail to create a bug for tracking. I think I'm happy to backport now (FSVO "now" depending on when I get a moment), since these are clearly en route to Linus. Note that after these patches SWP is still undef by default, this just adds the option to emulate (via a sysctl toggle). I don't propose to deviate from upstream here, since they have good reasons to prefer the current defaults. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417683172.2372.46.ca...@debian.org
Bug#771997: marked as done (swp on armv8 (Was: Haskell on arm needs help))
Your message dated Tue, 11 Jun 2019 15:04:21 +0200 with message-id <20190611130421.GA6530@pisco.westfalen.local> and subject line Re: swp on armv8 (Was: Haskell on arm needs help) has caused the Debian Bug report #771997, regarding swp on armv8 (Was: Haskell on arm needs help) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 771997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771997 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: linux Version: 3.16.7-2 Severity: important X-Debbugs-CC: debian-...@lists.debian.org On Thu, 2014-12-04 at 08:38 +, Ian Campbell wrote: > On Wed, 2014-12-03 at 23:23 +, peter green wrote: > > > I vaugely remember something a while back about some deprecated 32-bit > > arm instructions needing kernel emulation on armv8 and that emulation > > not being implemented yet. > > That's correct, and IIRC swp is one of those instructions. > > > AIUI swp is already handled through kernel emulation on armv7 > > multiprocessor systems. There seem to be patches to port that emulation > > to arm64 but it doesn't appear they are in the kernel tree debian is > > using. > > Having 32-bit binaries break on armv8 systems due to lack of the > > swp instruction does not seem like a good thing so IMO we really want > > this in our kernels before release. > > If those patches have gone into a later upstream kernel than we have in > Jessie (v3.16) then we should certainly backport them. IIRC they were > controversial though, so if they haven't hit mainline I'd be *very* > reluctant to "fork" the v8 userspace ABI. They are in the arm64 maintainer's for-next/core branch but not in Linus' tree (yet): $ git log --oneline v3.16..origin/master -- arch/arm64/kernel/armv8_deprecated.c $ git log --oneline v3.16..arm64/for-next/core -- arch/arm64/kernel/armv8_deprecated.c 9096339 arm64: fix return code check when changing emulation handler d784e29 arm64: Trace emulation of AArch32 legacy instructions c852f32 arm64: Emulate CP15 Barrier instructions bd35a4a arm64: Port SWP/SWPB emulation support from arm 587064b arm64: Add framework for legacy instruction emulation I've bcc'd submit@ on this mail to create a bug for tracking. I think I'm happy to backport now (FSVO "now" depending on when I get a moment), since these are clearly en route to Linus. Note that after these patches SWP is still undef by default, this just adds the option to emulate (via a sysctl toggle). I don't propose to deviate from upstream here, since they have good reasons to prefer the current defaults. Ian. --- End Message --- --- Begin Message --- On Thu, Dec 04, 2014 at 08:52:52AM +, Ian Campbell wrote: > Source: linux > Version: 3.16.7-2 > Severity: important > X-Debbugs-CC: debian-...@lists.debian.org > > On Thu, 2014-12-04 at 08:38 +, Ian Campbell wrote: > > On Wed, 2014-12-03 at 23:23 +, peter green wrote: > > > > > I vaugely remember something a while back about some deprecated 32-bit > > > arm instructions needing kernel emulation on armv8 and that emulation > > > not being implemented yet. > > > > That's correct, and IIRC swp is one of those instructions. > > > > > AIUI swp is already handled through kernel emulation on armv7 > > > multiprocessor systems. There seem to be patches to port that emulation > > > to arm64 but it doesn't appear they are in the kernel tree debian is > > > using. > > > Having 32-bit binaries break on armv8 systems due to lack of the > > > swp instruction does not seem like a good thing so IMO we really want > > > this in our kernels before release. > > > > If those patches have gone into a later upstream kernel than we have in > > Jessie (v3.16) then we should certainly backport them. IIRC they were > > controversial though, so if they haven't hit mainline I'd be *very* > > reluctant to "fork" the v8 userspace ABI. > > They are in the arm64 maintainer's for-next/core branch but not in > Linus' tree (yet): > $ git log --oneline v3.16..origin/master -- > arch/arm64/kernel/armv8_deprecated.c > $ git log --oneline v3.16..arm64/for-next/core -- > arch/arm64/ke
