https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #14 from Aldy Hernandez <aldyh 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 ?
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.
The above maps to the source: newlib/libc/sys/arm/syscalls.c
for (i = 0; i < MAX_OPEN_FILES; i ++)
openfiles[i].handle = -1;
openfiles[0].handle = monitor_stdin;
> > Should I run the dejagnu tests with -mcpu=xxxx or whatever, or is the
> > --with-cpu=cortex-a9 configury flag enough?
>
> Be paranoid - add the option. :-)
No difference :(.
