[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 23:44:07 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Build error for generic
On 07/07/2012 06:00 PM, jfoug wrote:
>> From: Frank Dittrich [mailto:frank_dittrich@...mail.com]
>> Now that this has arrived in magnum-jumbo, building generic on my 32bit
>> Linux system fails:
>
> I have changed the macro, from using the uintptr_t to using ARCH_WORD. I
> am pretty sure this will be adequate, since we are already properly (I hope)
> using the proper machine sized int for ARCH_WORD. The proper machine sized
> int was what uintptr_t was supposed to be.
Thanks.
With just the common.h change applied, generic build works again.
gcc 4.6.3 just produces two new warnings:
sha2.c: In function ‘sha256_final’:
sha2.c:240:2: warning: suggest parentheses around comparison in operand
of ‘&’ [-Wparentheses]
sha2.c: In function ‘sha512_final’:
sha2.c:564:2: warning: suggest parentheses around comparison in operand
of ‘&’ [-Wparentheses]
Line 240 is the same as line 564:
if (is_aligned(output,sizeof(ARCH_WORD_32))) {
is_aligned is defined in line 26 of common.h:
#define is_aligned(PTR, CNT) (((ARCH_WORD)(const void *)(PTR))&(CNT-1)==0)
With your common.h patch applied I get:
$ md5sum ../run/john
fda225c12f885de488ba1a9dbbf9f547 ../run/john
$ md5sum sha2.o
1f13dd90240316f69efb2b96d3cda1bc sha2.o
I am sure you must have meant
#define is_aligned(PTR, CNT) ((((ARCH_WORD)(const void *)(PTR))&(CNT-1))==0)
But if I change common.h that way, remove sha2.o, and
make generic again, I get:
$ md5sum ../run/john
5eac3b277c908a4caadcf8095be1d708 ../run/john
$ md5sum sha2.o
19c76d0c62d06fe0ab66eeafefacc4eb sha2.o
After a make clean generic, I get
$ md5sum ../run/john
b4d06ed3712d184b7b464275a8f7f2e4 ../run/john
$ md5sum sha2.o
19c76d0c62d06fe0ab66eeafefacc4eb sha2.o
Even though sha2.o remains unchanged and sha2.c is currently the only .c
file using is_aligned, the resulting binary changed!
Only when I change the #define to
#define is_aligned(PTR, CNT) (((ARCH_WORD)(const void *)(PTR))&((CNT-1)==0))
I do get the same sha2.o file as with your original patch:
$ md5sum sha2.o
1f13dd90240316f69efb2b96d3cda1bc sha2.o
But the resulting binary is different from the first one:
$ md5sum ../run/john
f44bbfd159c0198538b1a61c3b78239d ../run/john
I love reproducible results.
No wonder I got totally confused when at first I tried to compare just
the ../run/john binaries.
Looking at the operator precedence of & vs. ==, this should have ben
expected.
I am, however, quite sure this is not what you meant.
But may be I am confused.
Needless to say, the resulting john binaries all passed --test=0 runs,
no matter which way I changed the #define.
> I also changed code in the non-aligned CPU part of memory.c (in the
> non-aligned CPU's alter endianity), to use the is_aligned macro. This
> should help any problems show up faster.
Here you had a typo:
$ make generic > /dev/null
memory.c: In function ‘alter_endianity_w’:
memory.c:229:2: warning: implicit declaration of function ‘isaligned’
[-Wimplicit-function-declaration]
memory.o: In function `alter_endianity_w':
memory.c:(.text+0x6aa): undefined reference to `isaligned'
collect2: ld returned 1 exit status
make[1]: *** [../run/john] Error 1
make: *** [generic] Error 2
This should have been is_aligned instead of isaligned.
After fixing this, john can be built and passes --test=0.
Frank
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.
