https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Aldy Hernandez from comment #14) > (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 ? > > 1: x/i $pc > => 0x8c24 <initialise_monitor_handles+156>: strd r2, [r5, #12] > (gdb) info reg r5 > r5 0x1b6e8 112360 > (gdb) x/4x 0x1b6e8 > 0x1b6e8 <monitor_stdin>: 0x00000000 0x00000001 0x00000001 > 0xffffffff > > ...which is 64 bit aligned. And if you're curious what the 12 offset points to: (gdb) x/4x $r5 + 12 0x1b6f4 <openfiles>: 0xffffffff 0x00000000 0x00000001 0x000000 00 (gdb) x/4x $r5 + 0x12 0x1b6fa <openfiles+6>: 0x00000000 0x00010000 0x0000ffff 0xffff00 00
