selected processor does not support ARM mode

changed weight to 5

Here is a summary of the issue sent to ghc-devs,

Indeed this appears to be regression compared to 7.10.2 for some. However for most users it will be a significant improvement in stability.

ARM processors can run code encoded in one of several instruction sets of which ARM and Thumb are two. The issue here is that we have never been able to handle Thumb instructions correctly; we fare even worse in cases where we have Thumb and ARM instructions in the same executable due to various linker issues:

the runtime's linker doesn't support loading heterogeneous code at

all

the system's dynamic linker will almost certainly screw up our info

tables due to the need for a trampoline (for this reason , I'm not even sure whether it's possible to handle Thumb-ARM interworking in Haskell code)

There are several places where Thumb instructions could come from,

GHCi produced them in mkJumpToAddr

native code compiled with GCC, which defaults to Thumb on many

systems

system libraries, which are Thumb on many distributions

The solution which Erik implemented was to switch entirely to ARM. (1) was addressed by changing the GHC, (2) was fixed by explicitly passing -marm to GCC. I'm actually not sure the state of (3).

Regardless, the solution to (2) is clearly upsetting your system. This is odd as I was under the impression that all non-microcontroller ARM devices support the full ARM instruction set (the Cortex devices, on the other hand, only support Thumb but are totally incapable of running GHC at all). What hardware and distribution is this?

Cheers,

~ Ben

Yes, let’s continue the discussion here.

I don’t doubt that the patch is an important improvement! I am also slightly annoyed that Debian seems to be supporting a rather obsolete(?) ARM variant there... But it is one of the official Debian architectures, so this is a Debian-release-critical problem.

What hardware and distribution is this?

This is Debian’s armel architecture on experimental, “newer port using the "new" ABI (EABI), supported on ARM v4t and higher.”. More info on https://wiki.debian.org/ArmEabiPort

I *think* this is fixable, but it requires a bit of fiddling about. As noted by @joeyhess in #10469 the Clang/LLVM target triple for armel is armv4t-unknown-linux-gnueabi.

What we need to fix this is:

configure.ac needs to distinguish between Debian's armhf and armel.
compiler/llvmGen/LlvmCodeGen/Ppr.hs needs to set a different target triple depending on whether its build armel vs armhf.

This also assumes that GCC build for armel understands the -marm flag that was a significant part of the fix for #10375 (closed).

I'll see if I can get an armel chroot set up on one of my armhf boards to allow me to debug this. Assuming that works, I should have fix in a couple of days.

Ok, I have an armel chroot and I have reproduced this.

Tried simple hack of:

diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
index d7ddf80..03c369c 100644
--- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
@@ -50,7 +50,10 @@ moduleLayout = sdocWithPlatform $ \platform ->
     Platform { platformArch = ArchX86_64, platformOS = OSLinux } ->
         text "target datalayout = \"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64\""
         $+$ text "target triple = \"x86_64-linux-gnu\""
-    Platform { platformArch = ArchARM {}, platformOS = OSLinux } ->
+    Platform { platformArch = ArchARM { armISA = ARMv5 }, platformOS = OSLinux } ->
+        text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
+        $+$ text "target triple = \"armv4t-unknown-linux-gnueabihf\""
+    Platform { platformArch = ArchARM {}, platformOS = OSLinux } -> 
         text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
         $+$ text "target triple = \"armv6-unknown-linux-gnueabihf\""
     Platform { platformArch = ArchARM {}, platformOS = OSAndroid } ->

but then linking the RTS fails with:

/usr/bin/ar: creating rts/dist/build/libHSrts_thr_debug.a
/usr/bin/ld.gold: error: rts/dist/build/StgStartup.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/Updates.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/StgMiscClosures.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/Apply.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/HeapStackCheck.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/Exception.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/StgStdThunks.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/PrimOps.dyn_o uses VFP register arguments, output does not
/usr/bin/ld.gold: error: rts/dist/build/AutoApply.dyn_o uses VFP register arguments, output does not

By setting the LLVM target to armv4t-unknown-linux-gnueabihf, adding -float-abi=soft to the LLVM ABI options and adding -march=armv4t to the GCC command line I got something that builds part of the way, but the inplace/bin/ghc-stage2 binary segfaults on the first run.

Thanks for the progress so far. Do you already have an idea what might be causing the segfaults?

Unfortunately I don't, and what's worse is that when I use GDB on the stage2 compiler GDB itself hangs. Once I execute the GDB run command, I never get a prompt and the program doesn't terminate either.

This gets stranger still. If I simply revert commit 933adc0f31164cb651d (on master) it still doesn't build on armel.

Going to try build the debian ghc-7.10.2 package just to make sure I know what I'm doing.

Going to try build the debian ghc-7.10.2 package just to make sure I know what I'm doing.

Did that reveal anything interesting?

Trac metadata

Trac field	Value
CC	erikd → bgamari, erikd

Hello!

I'd be willing to help with this issue when this means we can keep ghc on armel in Debian.

In the meantime, I think it should be enough to build ghc on armel with --enable-unregisterised as this should always work, shouldn't it?

Adrian

Replying to [ticket:11058#comment:109556 erikd]:

This gets stranger still. If I simply revert commit 933adc0f31164cb651d (on master) it still doesn't build on armel.

Works here. I took 7.10.3-4 from Debian, reverted the change and was immediately able to build ghc again.

My suggested workaround in Debian is therefore to revert the change when compiling on armel while keeping the change on all other architectures. This will allow us to continue using ghc on armel again and in the future, this issue will hopefully be fixed properly.

Adrian

I believe this is now fixed. Perhaps someone could confirm this?

I just tried with 8.0.1-rc1, it is not fixed: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.0.0.20160111-3&stamp=1453130686

added ghc build failure label

added Pnormal label

Trac field	Value
Version	7.10.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	erikd
Operating system
Architecture

selected processor does not support ARM mode

Child items 0

Activity