Bug#807020: ghc: FTBFS on armel: selected processor does not support `strd r0, r1, [r7, #64]' in ARM mode

Erik de Castro Lopo erikd at mega-nerd.com
Mon Dec 21 19:43:45 UTC 2015


Joachim Breitner wrote:

> Am Sonntag, den 20.12.2015, 13:30 +0100 schrieb John Paul Adrian Glaubitz:
> > 
> > Well, the person who made the change which broke ghc on armel said that
> > and I assume he is working on it in the future. His change, on the other
> > hand, improved ghc on armhf. So nothing is saying he is not improved
> > ghc on armel, too.
> 
> that is close, but not precisely true. Erik aimed to improve GHC on ARM
> in general, and accidentally broke it on old ARM (armel in our speak).
> I notified him of that problem, and he gave it a shot, but got stuck at
> a segfaulting binary. Undoubtly he would have loved to have it fixed,
> but could at that point not make progress. So the signal I got from him
> was that it is unfortunate that it broke, but given that – in his
> opinion – GHC on ARM was in a somewhat broken state before across the
> board (after all, he had good reasons to do the change in the first
> place), this is only superficially a regression. Also I noticed that he
> stopped working on this particular issue. I do not blame him for that:
> Quite contrary, I’m grateful for his work.
> 
> But the signal was: Upstream considered the ARM situation in 7.10.2,
> although superficially compiling, so bad that his fix was of patch-
> level-release urgency. Armel was broken, and no one actively and
> urgently working on a patch. So therefore, it was only conclusive to
> upload that to unstable and – after an early enough warning to d-arm
> with none even saying that it would be pity, let along announce that
> they would invest time – requests its removals.
> 
> In particular, I do not consider these actions premature.
> 
> 
> I CCed Erik, not to necessarily to turn this into a wider discussion,
> but just to give him the chance to correct any wrong statement I might
> have made about what he did or the state of affairs.

The only thing I have to add is that GHC for armhf is even less
healthy that you think.

My change was to force GHC to generate Arm instructions throughout
and that got GHCi working on Armhf. That worked for the code in
the 7.10 tree. However, since that change, an update to libc broke
GHCi even on Armhf. The problem is again the thumb-interop stuff;
the need to be be able to seamlessly call from Arm to Thumb code
and vice versa.

Fixing this requires a lot of work, something I simply do not have
time for at the moment. I'm actually much more interested in fixing
GHCI on Arm64 which currently looks like a much easier task.

Anyway I think you are right. Reverting the patch on armel can
get GHC on armel back to where it was.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/



More information about the Pkg-haskell-maintainers mailing list