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

[Erik de Castro Lopo]

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/

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

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/20/2015 11:02 PM, Joachim Breitner wrote:
> ah, I was mislead by the mail address you use, but you are an
> uploading DD – so since you have built it anyways, why don’t you
> simply upload it?

No problem, will do. Just currently test-building the package on armhf
to be sure I didn't break anything. Then I'll have to make another
final clean build on armel since my first test patch wasn't cleaned
up yet.

> (If you are worried about historic Debian customs of being very
> careful about treading on other people’s packages – in my cases
> don’t :-))

Thanks. I just want to make sure I don't interfere with the work
of my fellow Debian Developers.

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWdzMKAAoJEHQmOzf1tfkTY/sP/2wUVGFLXW7surO6eBFo3ECg
yOUFZRE8qOXYiMs9++zJZfk1NZRcGHGrrO5OBNwrtO+CKldvDNBWPmO0zG/rhz+O
V4t8sk46pcPckVBt/IpOAa3MO8s7EQSOMl1pmFFQzJMIdh1BHeKkfbP/38g9H8QL
kYxKdQxFeyEw6yZrnMDV5443g5pxfw60zTo8hHTVQPjn+vk7uej2vq3BonB25eSN
SCVsN3aqKF24GZxurO9PwJl5M2lf3pqQdI0LVuK2F7WAFmBF3PJQ5Rs481+9/s0e
Rx0exzWEtrfzqP/eDA/+P5jiAETJERuMj2JiVZ60l2seBUvE9f9Jfo+oq395muEq
BPo42Zu+dhfoBBvxi2cGM2Fa04Tzbptq5q9R9SkGL4dnTV5Y8/yT86lYU79+IJh0
3CZGVSInsq//SF4lfK75rWrrSbjFgKZOyrYruoLl/G1XVLAYnyChKf9ty4FXbcPb
IQx3hup7kY/y+2urP7h0RLfW22pzG/3tEonfieDThK5v7M+qcKA39WJhmcSxVi+E
HAtvVUK9vWya8tJHA/VbKTcR9D9g/H1ZSrI4QOW2fKzYd0EetX37VeV6ioUIz2Yx
uIGPoA/v74GsJLYFg1oOMaKpWJC6prIxN9YTGoZcf3RCvM4z2egpGEnu08DPrMWX
ATZE9RXgfoVNJlmCrWP+
=g0dl
-END PGP SIGNATURE-

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

[Emilio Pozuelo Monfort]

On 20/12/15 14:02, John Paul Adrian Glaubitz wrote:
> On 12/20/2015 01:42 PM, Emilio Pozuelo Monfort wrote:
>> I know nothing about haskell upstream, so the fact that armel got broken for 
>> so
>> long even though it was pointed out by Joachim in several mails made me think
>> that arm(el) development had indeed been stopped.
> 
> Sorry, but this is complete non-sense.

Cool. So now worrying about the situation and long-term status of a key package
in a release architecture is called nonsense. Way to go.

Emilio

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

[John Paul Adrian Glaubitz]

Emilio,

On 12/20/2015 11:42 PM, Emilio Pozuelo Monfort wrote:
> Cool. So now worrying about the situation and long-term status of a key 
> package
> in a release architecture is called nonsense. Way to go.

Could you just please stop trolling, you're not helping, ok?
ARM is not dead by far stretch, so your assumptions *are* non-sense.

Instead of telling others what to do, I suggest you use your energy
to fix bugs instead or sponsor packages for Debian maintainers or
maybe help new people become DDs by becoming an AM.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joachim Breitner]

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.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

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

[Joachim Breitner]

Dear haskell-arm,


Adrian has invested the time and come up with a way to keep GHC alive
on armel. (Thanks a lot!)

Unfortunately, there was a race condition with him coming up with a
solution and my removal bug being acted upon by the ftp-masters, which
now means that we have to re-bootstrap GHC on armel to get Adria’s fix
in. Due to the restricted possibility of installing additional and out-
of-archive-packages in the porterbox schroots, I cannot do that dance.

Does any DD on this list have full access to a sufficiently strong
armel machine and is willing to doe the steps as described by Adrian,
described in the mail below? That would be great!

Thanks,
Joachim

Am Sonntag, den 20.12.2015, 11:09 +0100 schrieb John Paul Adrian
Glaubitz:
> Hi!
> 
> So, here's my suggestion on how to fix this issue.
> 
> First, copy the attached patch to the ghc source package but do
> not add it to the series file. Instead, add the following to
> debian/rules:
> 
> ifeq (armel,$(DEB_HOST_ARCH))
> 
> patch -p1 < debian/patches/armel-revert-ticket-10375.patch
> endif
> 
> This will revert the fix from upstream ticket 10375 but only for
> armel which will make the package build on armel again (I am
> currently
> doing a testbuild to verify this but it's still building after two
> days on armel on qemu).
> 
> Then manually build ghc on an armel machine with the above changes
> in a prepared changeroot with the build dependencies taken from
> snapshots.debian.org. This way we workaround the fact that ghc
> is BD-Uninstallable on armel.
> 
> Then create a new version of hscolour (can be just a cosmetic change
> just so that we can create a new package version) and build and
> upload
> the package manually on armel.
> 
> This should resolve this issue and make ghc build all the haskell
> packages on armel again.
> 
> I have also talked to upstream and the general opinion is that ARM
> support generally still needs lots of work, independent of this
> particular bug now so I assume that in the future, we will be able
> to drop this workaround again and hopefully have ghc's build system
> differenriate between armel and armhf which is what would have
> prevented
> this regression in the first place.
> 
> Cheers,
> Adrian
> 
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

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

[Joachim Breitner]

Dear debian-arm,

Adrian has invested the time and come up with a way to keep GHC alive
on armel. (Thanks a lot!)

Unfortunately, there was a race condition with him coming up with a
solution and my removal bug being acted upon by the ftp-masters, which
now means that we have to re-bootstrap GHC on armel to get Adria’s fix
in. Due to the restricted possibility of installing additional and out-
of-archive-packages in the porterbox schroots, I cannot do that dance.

Does any DD on this list have full access to a sufficiently strong
armel machine and is willing to doe the steps as described by Adrian,
described in the mail below? That would be great!

Thanks,
Joachim

Am Sonntag, den 20.12.2015, 11:09 +0100 schrieb John Paul Adrian
Glaubitz:
> Hi!
> 
> So, here's my suggestion on how to fix this issue.
> 
> First, copy the attached patch to the ghc source package but do
> not add it to the series file. Instead, add the following to
> debian/rules:
> 
> ifeq (armel,$(DEB_HOST_ARCH))
> 
> patch -p1 < debian/patches/armel-revert-ticket-10375.patch
> endif
> 
> This will revert the fix from upstream ticket 10375 but only for
> armel which will make the package build on armel again (I am
> currently
> doing a testbuild to verify this but it's still building after two
> days on armel on qemu).
> 
> Then manually build ghc on an armel machine with the above changes
> in a prepared changeroot with the build dependencies taken from
> snapshots.debian.org. This way we workaround the fact that ghc
> is BD-Uninstallable on armel.
> 
> Then create a new version of hscolour (can be just a cosmetic change
> just so that we can create a new package version) and build and
> upload
> the package manually on armel.
> 
> This should resolve this issue and make ghc build all the haskell
> packages on armel again.
> 
> I have also talked to upstream and the general opinion is that ARM
> support generally still needs lots of work, independent of this
> particular bug now so I assume that in the future, we will be able
> to drop this workaround again and hopefully have ghc's build system
> differenriate between armel and armhf which is what would have
> prevented
> this regression in the first place.
> 
> Cheers,
> Adrian
> 
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

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

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Joachim!

On 12/20/2015 10:36 PM, Joachim Breitner wrote:
> Does any DD on this list have full access to a sufficiently strong
>  armel machine and is willing to doe the steps as described by 
> Adrian, described in the mail below? That would be great!

You actually don't need native hardware for that, just use qemu-user.

I have written a short (German) howto that should help you to setup
an armel sbuild schroot on your amd64 box at home:

> https://people.debian.org/~glaubitz/sbuildsetup.html

With this setup, I was able to build ghc for armel without any issues,
takes around 12 hours on my 4-core Xeon E31220.

Hope this helps,

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWdyMOAAoJEHQmOzf1tfkTEi8QAKvLkkonoyGFZeDtP+K0ZRVy
Rx14fuVU7A4IK3iL2XCw1uJ/RUQnd64PKWuIy9esEBeSefJ7LGwoWXEOJV5oUgyR
L/H+RZMX9vwnh8Qs5gIDMDBuuP2XaSCqXVfueFrWvuMsUCNlrxTktBO7UPi7e3L7
JE3UT/qS+ImCQyVlP8Yvqc3laqIJVXxYHKY+Ru4c0KnyfkWRom8UZrqII6joEMme
hynUOp8AOe/ViFlEFn4C36Fr9X58glD3Y6c5ZMqLV6A3IKGnGLVioY4HfiDQhskB
O7vZZ24NtJeE1rusYdyTh2dPJwtPzCKAOQ//0Tyr+w15sNqY/jzRN8MOd2Uehz6g
gtJqPRAKkmI0kqPX27l5YOb5dqygjoNbfiM0viGWIuK2Kh5xHRW+JhejzE5VSerA
ZdM+e2ExqsgEC5icwYRlW2wgUB3oMiwFVCaE9Sik9HmdHqfxM7f02X29kuCgB4DS
EoJ9CmTeTdoVyL8kDXBzlpVUiU9lUUWG+EabLDw1nVNqKy4vmwD7j8iFuzhp8vKo
Sh4tNoFoXq4twyPNGj5VlYMwrAiOLKkSsHJj+c1+OwzjNW0V3blKJ15pg0Vp3Wju
y+R+lWVu7/7QhVLAq/iklKdFiw4mcUkWF4M9yIp2thcD9/zHafhEfeigw2jgRqgT
LYkVgARbJQ6jO2l96pBi
=WtyU
-END PGP SIGNATURE-

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

[Joachim Breitner]

Hi,

Am Sonntag, den 20.12.2015, 22:52 +0100 schrieb John Paul Adrian
Glaubitz:
> Hi Joachim!
> 
> On 12/20/2015 10:36 PM, Joachim Breitner wrote:
> > Does any DD on this list have full access to a sufficiently strong
> >  armel machine and is willing to doe the steps as described by 
> > Adrian, described in the mail below? That would be great!
> 
> You actually don't need native hardware for that, just use qemu-user.
> 
> I have written a short (German) howto that should help you to setup
> an armel sbuild schroot on your amd64 box at home:
> 
> > https://people.debian.org/~glaubitz/sbuildsetup.html
> 
> With this setup, I was able to build ghc for armel without any issues,
> takes around 12 hours on my 4-core Xeon E31220.

ah, I was mislead by the mail address you use, but you are an uploading
DD – so since you have built it anyways, why don’t you simply upload
it? 

(If you are worried about historic Debian customs of being very careful
about treading on other people’s packages – in my cases don’t :-))

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

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

[John Paul Adrian Glaubitz]

On 12/20/2015 01:42 PM, Emilio Pozuelo Monfort wrote:
> I know nothing about haskell upstream, so the fact that armel got broken for 
> so
> long even though it was pointed out by Joachim in several mails made me think
> that arm(el) development had indeed been stopped.

Sorry, but this is complete non-sense. Joachim's simply made a premature
reaction by requesting the removal of ghc:armel from the archive because
he assumed the problem was unfixable. But that's not the case, but
rather that ghc upstream haven't gotten around fixing the issue yet.

And I don't consider 4 months long time, it still worked with 7.10.2
and then Erik de Castro Lopo made an upstream change to improve ghc on
ARM without realizing that armel isn't compatible with this change. It's
simply a case of not testing your own changes. That's all.

> So your mail wasn't clear wrt whether development had been 
> restarted/continued,
> or your patch was just a one-off that wasn't going to improve things in the 
> long
> term.

Again, the situation is as follows: Erik was making general ARM
improvements and while doing that he broke something. He is aware of
that and realized in order to fix the problem properly, he will need
to make some larger changes which is understandable since ghc upstream
made the mistake that were lumping armel and armhf together even though
these should be considered as separate architectures.

So, the proper workaround here is simply to revert this change for
just armel and leave the patch applied for armhf where it actually
improved things.

> So while I understand that you have made an effort to fix this particular 
> issue,
> I just wanted to make sure that this wasn't going to break again in one month
> with noone noticing or caring, and armel support breaking again. It is good 
> that
> you have clarified that upstream is still actively working on arm*, so thanks
> for the clarification.

Of course not. Heck, I am fixing Debian on way more obscure or older
architectures like sh4 and m68k. armel is way too ubiquotous that we
should just drop it right away. Please let's keep Debian universal.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

Hi!

So, here's my suggestion on how to fix this issue.

First, copy the attached patch to the ghc source package but do
not add it to the series file. Instead, add the following to
debian/rules:

ifeq (armel,$(DEB_HOST_ARCH))

patch -p1 < debian/patches/armel-revert-ticket-10375.patch
endif

This will revert the fix from upstream ticket 10375 but only for
armel which will make the package build on armel again (I am currently
doing a testbuild to verify this but it's still building after two
days on armel on qemu).

Then manually build ghc on an armel machine with the above changes
in a prepared changeroot with the build dependencies taken from
snapshots.debian.org. This way we workaround the fact that ghc
is BD-Uninstallable on armel.

Then create a new version of hscolour (can be just a cosmetic change
just so that we can create a new package version) and build and upload
the package manually on armel.

This should resolve this issue and make ghc build all the haskell
packages on armel again.

I have also talked to upstream and the general opinion is that ARM
support generally still needs lots of work, independent of this
particular bug now so I assume that in the future, we will be able
to drop this workaround again and hopefully have ghc's build system
differenriate between armel and armhf which is what would have prevented
this regression in the first place.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff --git a/aclocal.m4 b/aclocal.m4
index 2282b99..0c2633a 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -568,18 +568,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS],
 $3="$$3 -D_HPUX_SOURCE"
 $5="$$5 -D_HPUX_SOURCE"
 ;;
-arm*linux*)
-# On arm/linux and arm/android, tell gcc to generate Arm
-# instructions (ie not Thumb) and to link using the gold linker.
-# Forcing LD to be ld.gold is done in FIND_LD m4 macro.
-$2="$$2 -marm"
-$3="$$3 -fuse-ld=gold -Wl,-z,noexecstack"
-$4="$$4 -z noexecstack"
-;;
-
-aarch64*linux*)
-# On aarch64/linux and aarch64/android, tell gcc to link using the
-# gold linker.
+arm*linux*   | \
+aarch64*linux*   )
+# On arm/linux, aarch64/linux, arm/android and aarch64/android, tell
+# gcc to link using the gold linker.
 # Forcing LD to be ld.gold is done in FIND_LD m4 macro.
 $3="$$3 -fuse-ld=gold -Wl,-z,noexecstack"
 $4="$$4 -z noexecstack"
diff --git a/compiler/ghci/ByteCodeItbls.hs b/compiler/ghci/ByteCodeItbls.hs
index a01fcd8..cd31acb 100644
--- a/compiler/ghci/ByteCodeItbls.hs
+++ b/compiler/ghci/ByteCodeItbls.hs
@@ -219,17 +219,17 @@ mkJumpToAddr dflags a = case platformArch (targetPlatform dflags) of
  , fromIntegral ((w64 `shiftR` 32) .&. 0x) ]
 
 ArchARM { } ->
--- Generates Arm sequence,
+-- Generates Thumb sequence,
 --  ldr r1, [pc, #0]
 --  bx r1
 --
 -- which looks like:
 --  <.addr-0x8>:
--- 0:   00109fe5ldrr1, [pc]  ; 8 <.addr>
--- 4:   11ff2fe1bx r1
+-- 0:   4900ldrr1, [pc]  ; 8 <.addr>
+-- 4:   4708bx r1
 let w32 = fromIntegral (funPtrToInt a) :: Word32
-in Left [ 0x00, 0x10, 0x9f, 0xe5
-, 0x11, 0xff, 0x2f, 0xe1
+in Left [ 0x49, 0x00
+, 0x47, 0x08
 , byte0 w32, byte1 w32, byte2 w32, byte3 w32]
 
 arch ->
diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
index d7ddf80..1a9373b 100644
--- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
@@ -52,7 +52,7 @@ moduleLayout = sdocWithPlatform $ \platform ->
 $+$ text "target triple = \"x86_64-linux-gnu\""
 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\""
+$+$ text "target triple = \"arm-unknown-linux-gnueabi\""
 Platform { platformArch = ArchARM {}, platformOS = OSAndroid } ->
 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 = \"arm-unknown-linux-androideabi\""
diff --git a/rts/Linker.c b/rts/Linker.c
index 355b33a..0a13e6f 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -5564,11 +5564,6 @@ do_Elf_Rel_relocations ( ObjectCode* oc, char* ehdrC,
 #ifdef arm_HOST_ARCH
  // Thumb instructions have bit 0 of symbol's st_value set
  

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

[John Paul Adrian Glaubitz]

On 12/20/2015 01:21 PM, Emilio Pozuelo Monfort wrote:
> needs a lot of work != someone is doing a lot of work on it. So unless someone
> is and you didn't say it, or you are volunteering to do it, I'm not sure how 
> the
> situation is going to improve.

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.

I don't understand the point of your message. I know that someone has
to do the work and I myself have already done a lot of work, too, not
just ghc. The message from the ghc is simply "we know it's broken and
we're going to fix it", that's all.

I assume ghc upstream development hasn't stopped, has it? Or what
exactly did you try to convey here?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Emilio Pozuelo Monfort]

On 20/12/15 13:30, John Paul Adrian Glaubitz wrote:
> On 12/20/2015 01:21 PM, Emilio Pozuelo Monfort wrote:
>> needs a lot of work != someone is doing a lot of work on it. So unless 
>> someone
>> is and you didn't say it, or you are volunteering to do it, I'm not sure how 
>> the
>> situation is going to improve.
> 
> 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.
> 
> I don't understand the point of your message. I know that someone has
> to do the work and I myself have already done a lot of work, too, not
> just ghc. The message from the ghc is simply "we know it's broken and
> we're going to fix it", that's all.
> 
> I assume ghc upstream development hasn't stopped, has it? Or what
> exactly did you try to convey here?

I know nothing about haskell upstream, so the fact that armel got broken for so
long even though it was pointed out by Joachim in several mails made me think
that arm(el) development had indeed been stopped.

So your mail wasn't clear wrt whether development had been restarted/continued,
or your patch was just a one-off that wasn't going to improve things in the long
term.

So while I understand that you have made an effort to fix this particular issue,
I just wanted to make sure that this wasn't going to break again in one month
with noone noticing or caring, and armel support breaking again. It is good that
you have clarified that upstream is still actively working on arm*, so thanks
for the clarification.

Cheers,
Emilio

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

[John Paul Adrian Glaubitz]

On 12/20/2015 11:09 AM, John Paul Adrian Glaubitz wrote:
> First, copy the attached patch to the ghc source package but do
> not add it to the series file. Instead, add the following to
> debian/rules:

PS: I will clean the patch up after I have verified it to work.
So please don't add it as-is.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Emilio Pozuelo Monfort]

On 20/12/15 11:09, John Paul Adrian Glaubitz wrote:
> I have also talked to upstream and the general opinion is that ARM
> support generally still needs lots of work, independent of this
> particular bug now so I assume that in the future, we will be able
> to drop this workaround again and hopefully have ghc's build system
> differenriate between armel and armhf which is what would have prevented
> this regression in the first place.

needs a lot of work != someone is doing a lot of work on it. So unless someone
is and you didn't say it, or you are volunteering to do it, I'm not sure how the
situation is going to improve.

Cheers,
Emilio

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

[John Paul Adrian Glaubitz]

On 12/20/2015 11:18 AM, John Paul Adrian Glaubitz wrote:
> PS: I will clean the patch up after I have verified it to work.
> So please don't add it as-is.

Alright, the fix works. Attaching a debdiff with my suggested
changes. As I said before, this package should be built on an
armel box and then have the buildds build ghc for the remaining
architectures.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/ghc-7.10.3/debian/changelog new/ghc-7.10.3/debian/changelog
--- old/ghc-7.10.3/debian/changelog	2015-12-14 09:09:52.0 +0100
+++ new/ghc-7.10.3/debian/changelog	2015-12-20 17:03:10.721723902 +0100
@@ -1,3 +1,12 @@
+ghc (7.10.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/armel-revert-ghci-fixes.patch which reverts
+the ARM ghci fixes, but apply the patch on armel only with
+the help of the debian/rules file (Closes: #807020).
+
+ -- John Paul Adrian Glaubitz   Sun, 20 Dec 2015 17:01:39 +0100
+
 ghc (7.10.3-4) unstable; urgency=medium
 
   [ Colin Watson ]
diff -Nru old/ghc-7.10.3/debian/patches/armel-revert-ghci-fixes.patch new/ghc-7.10.3/debian/patches/armel-revert-ghci-fixes.patch
--- old/ghc-7.10.3/debian/patches/armel-revert-ghci-fixes.patch	1970-01-01 01:00:00.0 +0100
+++ new/ghc-7.10.3/debian/patches/armel-revert-ghci-fixes.patch	2015-12-20 16:45:04.111264142 +0100
@@ -0,0 +1,86 @@
+Description: Revert ghci ARM improvements (ticket #10375) on armel
+ This patch reverts a change which improved ghci on ARM (see
+ ghc ticket #10375). While the change fixed ghci on armhf, it
+ actually resulted in the ghc package FTBFS on armel since the
+ changes introduced made ghc incompatible with this architecture
+ (ticket #11058). As a temporary workaround, we revert this particular
+ change when ghc is built on armel. For this reason, this patch
+ is not applied using the series file but only selectively on
+ armel with the help of debian/rules.
+ .
+
+--- ghc-7.10.3.orig/aclocal.m4
 ghc-7.10.3/aclocal.m4
+@@ -574,18 +574,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS],
+ $3="$$3 -D_HPUX_SOURCE"
+ $5="$$5 -D_HPUX_SOURCE"
+ ;;
+-arm*linux*)
+-# On arm/linux and arm/android, tell gcc to generate Arm
+-# instructions (ie not Thumb) and to link using the gold linker.
+-# Forcing LD to be ld.gold is done in FIND_LD m4 macro.
+-$2="$$2 -marm"
+-$3="$$3 -fuse-ld=gold -Wl,-z,noexecstack"
+-$4="$$4 -z noexecstack"
+-;;
+-
+-aarch64*linux*)
+-# On aarch64/linux and aarch64/android, tell gcc to link using the
+-# gold linker.
++arm*linux*   | \
++aarch64*linux*   )
++# On arm/linux, aarch64/linux, arm/android and aarch64/android, tell
++# gcc to link using the gold linker.
+ # Forcing LD to be ld.gold is done in FIND_LD m4 macro.
+ $3="$$3 -fuse-ld=gold -Wl,-z,noexecstack"
+ $4="$$4 -z noexecstack"
+--- ghc-7.10.3.orig/compiler/ghci/ByteCodeItbls.hs
 ghc-7.10.3/compiler/ghci/ByteCodeItbls.hs
+@@ -219,17 +219,17 @@ mkJumpToAddr dflags a = case platformArc
+  , fromIntegral ((w64 `shiftR` 32) .&. 0x) ]
+ 
+ ArchARM { } ->
+--- Generates Arm sequence,
++-- Generates Thumb sequence,
+ --  ldr r1, [pc, #0]
+ --  bx r1
+ --
+ -- which looks like:
+ --  <.addr-0x8>:
+--- 0:   00109fe5ldrr1, [pc]  ; 8 <.addr>
+--- 4:   11ff2fe1bx r1
++-- 0:   4900ldrr1, [pc]  ; 8 <.addr>
++-- 4:   4708bx r1
+ let w32 = fromIntegral (funPtrToInt a) :: Word32
+-in Left [ 0x00, 0x10, 0x9f, 0xe5
+-, 0x11, 0xff, 0x2f, 0xe1
++in Left [ 0x49, 0x00
++, 0x47, 0x08
+ , byte0 w32, byte1 w32, byte2 w32, byte3 w32]
+ 
+ arch ->
+--- ghc-7.10.3.orig/compiler/llvmGen/LlvmCodeGen/Ppr.hs
 ghc-7.10.3/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+@@ -52,7 +52,7 @@ moduleLayout = sdocWithPlatform $ \platf
+ $+$ text "target triple = \"x86_64-linux-gnu\""
+ 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\""
++$+$ text "target triple = \"arm-unknown-linux-gnueabi\""
+ Platform { platformArch = ArchARM {}, platformOS = OSAndroid } ->
+ 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\""
+ 

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

[Joachim Breitner]

Hi,

this is unfortunate, but known. GHC (and hence all of Haskell) will be
removed from the archive soonish.

See  https://lists.debian.org/debian-arm/2015/11/msg00010.html and
https://lists.debian.org/debian-arm/2015/12/msg00020.html

Greetings,
Joachim

Am Freitag, den 04.12.2015, 11:14 +0100 schrieb Emilio Pozuelo Monfort:
> Source: ghc
> Version: 7.10.3-2
> Severity: serious
> 
> Your package failed to build on 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/ghc074d_0/ghc_7.s: Assembler messages:
> 
> /tmp/ghc074d_0/ghc_7.s:96:0:
>  Error: selected processor does not support `ldrd r0,r1,[r3,#64]'
> in ARM mode
> 
> /tmp/ghc074d_0/ghc_7.s:99:0:
>  Error: selected processor does not support `strd r0,r1,[r3,#64]'
> in ARM mode
> 
> /tmp/ghc074d_0/ghc_7.s:210:0:
>  Error: selected processor does not support `ldrd r0,r1,[r7,#64]'
> in ARM mode
> 
> /tmp/ghc074d_0/ghc_7.s:214:0:
>  Error: selected processor does not support `strd r0,r1,[r7,#64]'
> in ARM mode
> rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o'
> failed
> 
> Full log at:
> 
> https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=7.1
> 0.3-2=1449207555
> 
> Emilio
> 
> ___
> Pkg-haskell-maintainers mailing list
> pkg-haskell-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-haskell-m
> aintainers
> 
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

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

[Emilio Pozuelo Monfort]

Source: ghc
Version: 7.10.3-2
Severity: serious

Your package failed to build on 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/ghc074d_0/ghc_7.s: Assembler messages:

/tmp/ghc074d_0/ghc_7.s:96:0:
 Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM 
mode

/tmp/ghc074d_0/ghc_7.s:99:0:
 Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM 
mode

/tmp/ghc074d_0/ghc_7.s:210:0:
 Error: selected processor does not support `ldrd r0,r1,[r7,#64]' in ARM 
mode

/tmp/ghc074d_0/ghc_7.s:214:0:
 Error: selected processor does not support `strd r0,r1,[r7,#64]' in ARM 
mode
rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed

Full log at:

https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=7.10.3-2=1449207555

Emilio