https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Richard Earnshaw from comment #16) > (In reply to Nick Clifton from comment #13) > > Hi Aldy, > > > > > > > pc: 8ca4, instr: e1c520fc > > > pc: 4, instr: ea00089b > > > > > > I took a peek at the executable being run with "/my-arm-build/objdudump -D > > > the-executable.exe", and I see we are failing in > > > initialise_monitor_handles(). > > > This suggests we're failing during the start-up code: > > > > > 8ca4: e1c520fc strd r2, [r5, #12] > > > > > > It seems that last store is corrupting things and making us jump to a PC > > > of > > > 4??? > > > > Address 4 is the "undefined instruction" vector. If the simulator thinks > > that the instruction is illegal/unknown then it will branch to address 4 > > and start executing from there. (Or else it loads the value stored at > > address 4 and starts executing from that address. I forget which). > > > > So, this basically means that the simulator does not like that STRD > > instruction. :-( Looking at the code in Handle_Store_Double() in > > sim/arm/armemu.c, I think that the reason is probably because the address > > for the store is not double word aligned. Which leads me to wonder, > > what value is stored in r5 when the STRD instruction is being executed ? > > You wouldn't take the undef vector for an alignment issue: that would take a > data abort. > > Sounds like your simulator is built for an older architecture, that doesn't > have strd (ie it's pre-armv5te). Actually, Nick is correct. The simulator stops around here: /* The address must be aligned on a 8 byte boundary. */ if (addr & 0x7) { #ifdef ABORTS ARMul_DATAABORT (addr); #else ARMul_UndefInstr (state, instr); #endif (gdb) p/x addr $26 = 0x1b6f4 (gdb) p/x addr & 7 $27 = 0x4 and ARMul_UndefInstr() is: void ARMul_UndefInstr (ARMul_State * state, ARMword instr ATTRIBUTE_UNUSED) { ARMul_Abort (state, ARMul_UndefinedInstrV); } #define ARMUndefinedInstrV 4L ... #define ARMul_UndefinedInstrV ARMUndefinedInstrV The 4 is not exactly intuitive... I still think someone with access to a working environment should reduce or debug this further :(.