Joachim Breitner wrote:
I think the default chroot arch follows the userland arch of the "outer system" and the outer system on asachi is armhf.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 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.
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.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.)
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,
Theres a few armv7 porterboxes available though with lower resources than asachiShould I use a different machine to debug armel build failures? Or is ghc in unstable (and hence testing) that broken on armel?
abel.debian.org (I think this is the best resourced one) harris.debian.org ipa.debian.net (non-dsa)