Denis Protivensky via llvm-dev
2015-Sep-07 08:43 UTC
[llvm-dev] POssible bug in the Arm code generator
Hi Erik,> GHC does not generate or use thumb instructionsFrom 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>
Renato Golin via llvm-dev
2015-Sep-07 11:13 UTC
[llvm-dev] POssible bug in the Arm code generator
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
Erik de Castro Lopo via llvm-dev
2015-Sep-08 05:29 UTC
[llvm-dev] POssible bug in the Arm code generator
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 codeNope, 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/