Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]'
Hi, I cannot build ghc-7.10.3 on Debian armel: "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 Erik, can you comment on that? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Isn't armel the (old, but not EABI-very-old) pre-hardware-floating point ABI?
In any case, this is fallout from
933adc0f31164cb651d11ecfcfe612ac429f714f, but fixing it means we'd
need to add in several more code paths to handle this case... So I
suppose we should probably file a ticket and get that fixed for 8.0
On Tue, Nov 3, 2015 at 6:37 AM, Joachim Breitner
Hi,
I cannot build ghc-7.10.3 on Debian armel:
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages:
/tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]'
/tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]'
/tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]'
/tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2
Erik, can you comment on that?
Greetings, Joachim
-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
Hi, Am Dienstag, den 03.11.2015, 08:47 -0600 schrieb Austin Seipp:
Isn't armel the (old, but not EABI-very-old) pre-hardware-floating point ABI?
I believe so, but I’m sure Erik knows better.
In any case, this is fallout from 933adc0f31164cb651d11ecfcfe612ac429f714f, but fixing it means we'd need to add in several more code paths to handle this case... So I suppose we should probably file a ticket and get that fixed for 8.0
Well, it is a regression over 7.10.2; such a thing should not happen in a stable point release, shouldn’t it? Filed a ticket at https://ghc.haskell.org/trac/ghc/ticket/11058 Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Joachim Breitner
Hi,
Am Dienstag, den 03.11.2015, 08:47 -0600 schrieb Austin Seipp:
Isn't armel the (old, but not EABI-very-old) pre-hardware-floating point ABI?
I believe so, but I’m sure Erik knows better.
In any case, this is fallout from 933adc0f31164cb651d11ecfcfe612ac429f714f, but fixing it means we'd need to add in several more code paths to handle this case... So I suppose we should probably file a ticket and get that fixed for 8.0
Well, it is a regression over 7.10.2; such a thing should not happen in a stable point release, shouldn’t it?
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, 1. GHCi produced them in mkJumpToAddr 2. native code compiled with GCC, which defaults to Thumb on many systems 3. 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
Ben Gamari wrote:
There are several places where Thumb instructions could come from,
1. GHCi produced them in mkJumpToAddr
2. native code compiled with GCC, which defaults to Thumb on many systems
3. 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).
Unfortunately, (3) is likely to still be broken. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Joachim Breitner wrote:
Erik, can you comment on that?
Well, I agree that not being able to build GHC on `armel` is a regression with respect to 7.10.2, but in my opinion, GHC 7.10.2 was not actually usable on Arm, at least not on `armhf` (not sure about `armel` as I don't have an `armel` setup). Currently, GHC treats all 32 bit Arm systems as the same. I think this shows that we need at least the equivalent of Debian's `armhf` (which is what we currently have) and Debian's `armel`. I'm not even too sure what `armel` actually is. Is it Armv4 with softfloat? Is so, I can probably create a chroot on one of my fast `armhf` boards. The main problem is that Arm needs more developer man power. For the last several months my employer has allowed me to allocate some of my work hours to improve GHC on Arm and Arm64. That however is about to come to an end and at the moment I seem to be the only person working on Arm. That work is also made more difficult by the fact that changes in the master branch seem to break Arm (and/or PowerPC) every 2-3 weeks. Sometimes just fixing new breakage in master takes up all the time I have. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
participants (4)
-
Austin Seipp -
Ben Gamari -
Erik de Castro Lopo -
Joachim Breitner