Opened 5 years ago

Closed 5 years ago

#9691 closed bug (wontfix)

GHC-HEAD runtime is broken on arm

Reported by: mkbrandt Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.9
Keywords: Cc: erikd
Operating System: Linux Architecture: arm
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I incorporated the patch from #9593 and built GHC HEAD as a cross compiler for arm-unknown-linux-gnueabi.

mbrandt@ubuntu:~/ghc-head$ arm-unknown-linux-gnueabi-ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20141014

The resulting compiler will compile programs and link them resulting in what appears to be a valid executable (testme.hs is a simple hello world app):

mbrandt@ubuntu:~/ghc-head$ file testme testme: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=11ca9da291edb0428c977e506ac1a8f1e398aa57, not stripped

When run on the target (an i.MX280 - ARM9EJ-S) the runtime gets hung up before main is evaluated. The program is using 90+% cpu.

This behavior is consistent for both HEAD and ghc-7.8.3 with both registerized and unregisterized builds.

Change History (5)

comment:1 Changed 5 years ago by mkbrandt

I tried building ghc-7.8.3 for arm-unknown-linux-gnueabi after installing the ELDK to make the environment easier to duplicate. ELDK was version 5.5 configured for armv5te. I confirmed that gcc binaries produced by this SDK would run on the target, but got the same result with arm-unknown-linux-ghc (binary hangs with no output using ~100% of cpu).

comment:2 Changed 5 years ago by erikd

Cc: erikd added

I'm seeing something very similar with git head (b8392ae76a6d39) cross compiling (using llvm-3.5) from a Debian amd64-linux to arm-linux-gnueabihf (beaglebone-black running Debian). My test program is:

main :: IO ()
main = putStrLn "Hello"

and when I copy the compiled binary to the beaglebone and run it, it segfaults almost immediately. The GDB backtrace looks like this:

Program received signal SIGSEGV, Segmentation fault.
0x0021b8dc in stg_init_finish$def ()
(gdb) bt
#0  0x0021b8dc in stg_init_finish$def ()
#1  0x00217116 in threadPaused ()
#2  0x00000000 in ?? ()
Last edited 5 years ago by erikd (previous) (diff)

comment:3 Changed 5 years ago by erikd

Very similar problem on native arm -> arm compiler (again using llvm-3.5):

Program received signal SIGSEGV, Segmentation fault.
0x01d0a278 in stg_init_finish$def ()
(gdb) bt
#0  0x01d0a278 in stg_init_finish$def ()
#1  0x01d031b2 in threadPaused ()
#2  0x4023f8ca in phys_pages_info (format=0x1 <error: Cannot access memory
    at address 0x1>) at ../sysdeps/unix/sysv/linux/getsysstats.c:314
#3  0x01d00dd4 in schedule ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Last edited 5 years ago by erikd (previous) (diff)

comment:4 Changed 5 years ago by erikd

This is a duplicate of #9920 (which has far more analysis and a solution). Ok, to close this one?

Update: These may not be identical. My suggestion is to recompile llvm 3.5 with the patch from #9920 and try building a cross-compiler with that.

Last edited 5 years ago by erikd (previous) (diff)

comment:5 Changed 5 years ago by erikd

Resolution: wontfix
Status: newclosed

I now have a Jenkins instance that builds and tests a linux/amd64 to linux/armhf and linux/arm64 cross-compiler from GHC git HEAD. These builds have be stable for a couple of weeks now.

GHC git HEAD works because it uses the llvm 3.6 release. The GHC 7.8.* releases don't work with the released llvm-3.5 version, but the patch from #9920 applied to llvm-3.5 fixes that.

Note: See TracTickets for help on using tickets.