llvm dev - Sep 2015 - 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.
> Owen Shepherd wrote:
>
>> Pay closer attention to the instruction descriptions on the page you
linked
>> above:
>>
>> LDR{*type*}{*cond*}*Rt*, [*Rn*  {, #*offset*}]        ; immediate
offset
>>
>> LDR{*type*}{*cond*}*Rt*, [*Rn*, #*offset*]!          ; pre-indexed
>>
>>
>> The pre-indexed form is always specified with an offset, and* follows
the
>> brackets with an exclamation mark*. You have an immediate offset load,
for
>> which Rt==Rn is permitted.
> Ah, missed that.
>
>> A possible reason for an illegal instruction exception is that you have
>> generated some ARM code and tried to execute it as Thumb or vise-versa.
> Well, I'm getting SIGILL, but GHC does not generate or use thumb
instructions
> and the SIGILL happens after susccessfuly running a bunch of other arm
> instructions. From GDB:
>
>    Program received signal SIGILL, Illegal instruction.
>    0x03ff9dbc in stg_ap_v_fast ()
>    (gdb) bt
>    #0  0x03ff9dbc in stg_ap_v_fast ()
>    #1  0x03fc6ce6 in StgRun (f=0x3ff9db4 <stg_ap_v_fast>,
basereg=0x49d2090 <MainCapability+16>) at
>        rts/StgCRun.c:81
>    #2  0x03fca52a in schedule (initialCapability=0x49d2080
<MainCapability>, task=0x49e62c0) at
>        rts/Schedule.c:524
>    #3  0x03fcc5e6 in scheduleWaitThread (tso=0xb6c07000, ret=0x0,
pcap=0xbeffeb74) at
>        rts/Schedule.c:2429
>    #4  0x03fbc7e4 in rts_evalLazyIO (cap=0xbeffeb74, p=0x402d470
<ZCMain_main_closure>, ret=0x0) at
>        rts/RtsAPI.c:500
>    #5  0x03fce2be in hs_main (argc=3, argv=0xbeffed64,
main_closure=0x402d470 <ZCMain_main_closure>,
>        rts_config=...) at rts/RtsMain.c:64
>    #6  0x00141508 in main ()
>    (gdb) disassemble
>    Dump of assembler code for function stg_ap_v_fast:
>       0x03ff9db4 <+0>:     push    {r7, lr}
>       0x03ff9db6 <+2>:     sub     sp, #32
>       0x03ff9db8 <+4>:     add     r7, sp, #0
>       0x03ff9dba <+6>:     ldr     r3, [pc, #508]  ; (0x3ff9fb8
<stg_ap_v_fast+516>)
>    => 0x03ff9dbc <+8>:     ldr     r3, [r3, #0]
>       0x03ff9dbe <+10>:    and.w   r3, r3, #3
>
>
> Erik
> -- 
> ---------------------------------------------------------------------- 
> Erik de Castro Lopo http://www.mega-nerd.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150907/ebd0a455/attachment.html>

On 7 September 2015 at 09:43, Denis Protivensky via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > 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.
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.

Renato Golin via llvm-dev wrote:
> 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:

    https://ghc.haskell.org/trac/ghc/ticket/10375

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
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/