POssible bug in the Arm code generator

Hi Erik,

GHC does not generate or use thumb instructions

From you assembly dump, looks like the instructions are 2 bytes long, meaning it’s Thumb code not ARM.

  • Denis.

This could be some library code that you're calling without using
branch exchange. Maybe you're compiling specifically disabling
interworking?

Can you give us a bit more context? What's your CPU, and what are your
back-end options in GHC?

cheers,
--renato

Thanks to everyone who has responded so far. I'm just beginning to find
out how much I still don't know about Arm.

This could be some library code

Nope, this is the core GHC binary run with the '--interactive'
command line option.

that you're calling without using branch exchange.

Today I learned about the "bx" instruction.

Maybe you're compiling specifically disabling
interworking?

You mean its possible to disable Thumb instructions altogether?
I would like to try that if its as easy as passing an additional
command line parameter to llc or opt.

Can you give us a bit more context?

The context is me debugging an illegal instruction problem that
is fully documented in all its horrid glory here:

    arm: ghci hits an illegal instruction (#10375) · Issues · Glasgow Haskell Compiler / GHC · GitLab

TL;DR is I have at least two different Arm boards that hit this
problem even though apart from this problem the compiler actually
does work.

What's your CPU,

The two boards are:

* Qualcomm APQ 8084 (Flattened Device Tree)
* ODROID-XU3

and he CPUs are listed as

* ARMv7 Processor rev 1 (v7l)
* ARMv7 Processor rev 3 (v7l)

respectively, both running Debian testing and using the debian
llvm-3.6 packaged binaries.

and what are your back-end options in GHC?

The only non-standard thing I am doing is passing `--enable-unregistererised`
to the configure script to disable GHC calling convention (because GDB
doesn't understand it (yet)).

The build process is as follows:

* Debian packaged ghc-7.8.4 builds ghc-stage1 from the git repo.
* ghc-stage1 builds ghc-stage2

and its ghc-stage2 that exhibits this problem. I can't test ghc-stage1
because the interactive command line feature is disabled in the stage1
compiler.

At ealier stanges of debugging this I though it was a problem with
GHC runtime linker. I still have not discounted that as a possibility.

Cheers,
Erik

Nope, this is the core GHC binary run with the '--interactive'
command line option.

Right, so the GCH is compiled in Thumb2 mode, while you're only
generating ARM code, and then calling one from another without branch
exchange will give you headaches. :slight_smile:

You mean its possible to disable Thumb instructions altogether?
I would like to try that if its as easy as passing an additional
command line parameter to llc or opt.

No, interchange means allowing ARM to call Thumb and vice-versa.
Essentially, enabling the emission of branch exchange.

From what I see, arm-interworking is enabled by default, so it's

possible that the code generator has no way of knowing which ISA
you're using on the other end because that's not in generated code,
but in your own interpreter.

I don't know how the JIT does it, but there has to be a way to force
BX/BLX on every call.

* ARMv7 Processor rev 1 (v7l)
* ARMv7 Processor rev 3 (v7l)

Right, pretty standard.

The only non-standard thing I am doing is passing `--enable-unregistererised`
to the configure script to disable GHC calling convention (because GDB
doesn't understand it (yet)).

That's not what I meant. I'm assuming you're using the JIT, and that
you're initializing the native target and passing the target data to
the pass manager, etc.

There could be some specialised options that the GHC is doing to
create the ARM target, specifically enabling and disabling stuff that
could be impacting the code generation.

At ealier stanges of debugging this I though it was a problem with
GHC runtime linker. I still have not discounted that as a possibility.

When you capture the signal, do a backtrace and see if the previous
frame is using branch exchange. That will give you a hint that we're
on the right track.

cheers,
--renato