[llvm-dev] POssible bug in the Arm code generator

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 9 06:59:57 PDT 2015


On 8 September 2015 at 06:29, Erik de Castro Lopo via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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. :)


> 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


More information about the llvm-dev mailing list