https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #16 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (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).
