[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1A6E5B8D-660F-43E8-A59C-4BE315AF845F@gmail.com>
Date: Sun, 9 Aug 2015 20:50:05 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR on ARM (NEON)
> On Aug 6, 2015, at 9:21 PM, Solar Designer <solar@...nwall.com> wrote:
>
>> However, I have some problem with the emulation of vroti. Literally, it should be defined this way:
>>
>> #define vroti_epi32(x, i) \
>> (i > 0 ? vsliq_n_u32(vshrq_n_u32(x, 32 - (i)), x, i) : \
>> vsriq_n_u32(vshlq_n_u32(x, 32 + (i)), x, -(i)))
>>
>> Somehow it won't compile when and only when building rawSHA1_ng_fmt_plug.o, giving some cryptic error message:
>>
>> /tmp/ccgVmq2d.s: Assembler messages:
>> /tmp/ccgVmq2d.s:4397: Error: co-processor offset out of range
>
> You may capture this assembly output and see what's on that line, then
> try to match it back to a source code line. But yes, I think it's a
> compiler bug.
The source file rawSHA1_ng_fmt_plug.c is really making some trouble here. When compiled on ZedBoard with gcc 4.6.1, it caused the compiler to segfault:
rawSHA1_ng_fmt_plug.c: In function 'sha1_fmt_cmp_all':
rawSHA1_ng_fmt_plug.c:789:1: internal compiler error: Segmentation fault
This time I didn't use the 2-instruction emulation of vroti, so it's not to blame. I have to temporarily disable this format for ARM.
Lei
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
