Bernhard Übelacker <bernha...@mailbox.org> writes:
> Dear Maintainer,
> I tried to collect some more information and compared this
> situation on real hardware armv5tel with an armv7 and
> it looks like in keccak_finalize the following instruction
> stores different data to memory depending on the arm hardware:
>
> 0x005c4ac0 <keccak_finalize+192>: f0 20 c4 e1 strd r2, [r4]
>
> In the failing case this is stored:
> (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
> 0xbeffef5c: 0x6f 0x6e 0x20 0x63 0x00 0x00 0x00
> 0x00
>
> And in the good case this:
> (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
> 0xbeffef5c: 0x2e 0x6f 0x6e 0x69 0x6f 0x6e 0x20
> 0x63
>
> While on both the registers r2 and r3 contain:
> r2 0x696e6f2e 1768845102
> r3 0x63206e6f 1663069807
>
> In the attached files are some more details leading to the above result.
>
Woah Bernhard, that's some top-notch detective work!
I wonder what this means? Does this mean that strd is broken on that
armv5tel, or that we are running gcc with the wrong flags for this
architecture?
The only relevant google result I could find is this post from 2007:
https://www.redhat.com/archives/rhl-devel-list/2007-June/msg01002.html
