Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Mar 2015 08:28:38 +0800
From: Lei Zhang <>
Subject: Re: [GSoC] building JtR for MIC

Oh, I forgot the attachment.

icc -mmic -DAC_BUILT -no-opt-prefetch -c -g -O2 -DARCH_LITTLE_ENDIAN=1  -D_GNU_SOURCE    -fopenmp  -pthread  -I/home/zhanglei/mic/include  jumbo.c -o jumbo.o
In file included from jumbo.c(14):
jumbo.h(80): warning #1224: #warning directive: Using 32-bit fseek(). Files larger than 2GB will be handled unreliably
  #    warning Using 32-bit fseek(). Files larger than 2GB will be handled unreliably

In file included from jumbo.c(14):
jumbo.h(122): warning #1224: #warning directive: Using 32-bit ftell(). Files larger than 2GB will be handled unreliably
  #    warning Using 32-bit ftell(). Files larger than 2GB will be handled unreliably

In file included from jumbo.h(29),
                 from os-autoconf.h(29),
                 from os.h(20),
                 from memdbg.h(20),
                 from jumbo.c(27):
/usr/linux-k1om-4.7/linux-k1om/usr/include/string.h(459): error: expected a type specifier
  extern void bzero (void *__s, size_t __n) __THROW __nonnull ((1));

jumbo.c(257): warning #147: declaration is incompatible with "int strcasecmp(const char *, const char *)" (declared at line 225 of "jumbo.h")
  int strcasecmp(char *dst, char *src) {

jumbo.c(265): error: expected an expression
  	return return(f - l);

jumbo.c(270): warning #147: declaration is incompatible with "int strncasecmp(const char *, const char *, size_t={unsigned long})" (declared at line 246 of "jumbo.h")
  int strncasecmp(char *dst, char *src, size_t count) {

compilation aborted for jumbo.c (code 2)

> On Mar 19, 2015, at 8:59 PM, Lei Zhang <> wrote:
> Hi Alexander,
> Actually using your original mic.h with autoconf results in some compile errors. I modified mic.h to include autoconfig.h and those compile errors were gone. 
> I didn't encounter those errors previously because I mistakenly set ARCH_LINK=autoconf_arch.h. And when I set it to mic.h, those errors suddenly appeared. The error message is attached below.
> I think there're some bugs whose behavior rely on the definition of macros defined in autoconfig.h. Maybe I'll have to deal with those bugs anyway.
> Lei
>> On Mar 18, 2015, at 6:38 PM, Solar Designer <> wrote:
>> On Wed, Mar 18, 2015 at 05:27:45PM +0800, Lei Zhang wrote:
>>> I tweaked with OMP_SCALE in several formats, according to magnum's advices, and their memory usage on MIC is much more reasonable now. With OpenMP enabled, john-jumbo won't abort anymore when running the benchmark, although 126 of the tests still FAILED.
>> That's a huge number.  How many of the failed tests are for dynamic*
>> formats?  Perhaps there's one or a handful of bugs that are causing most
>> of the failures.
>> I notice that in jumbo my original mic.h is modified to use autoconf'ed
>> ARCH_* settings:
>> #if AC_BUILT
>> #include "autoconfig.h"
>> #else
>> #define ARCH_WORD                       long
>> #define ARCH_SIZE                       8
>> #define ARCH_BITS                       64
>> #define ARCH_BITS_LOG                   6
>> #define ARCH_BITS_STR                   "64"
>> #define ARCH_LITTLE_ENDIAN              1
>> #define ARCH_INT_GT_32                  0
>> #endif
>> This might be wrong since we're cross-compiling.  I doubt it's causing
>> trouble now, though, since the host system is almost certainly x86_64,
>> for which these settings just happen to be the same.
>>> Next I want to figure out how those tests failed, but I have a few questions first: (forgive me if they look stupid...)
>>> 1. What exactly does it mean for a format to FAIL the test?
>> See formats.c: fmt_self_test().  It's usually indicated after a call to
>> which of the format methods the test failed, but you'll most commonly
>> see get_hash[0](0) or something, which means that the actual failure was
>> likely in a preceding crypt_all() or set_key() or set_salt().  The test
>> vectors are in the tests[] array in each format's *_fmt*.c file.
>> In some cases, it's possible to narrow the problem down by temporarily
>> commenting out some of the test vectors.  But usually not.
>>> 2. There're two kind of numbers in the output, real and virtual. What's their difference?
>> This is in the FAQ:
>> Q: What are the "real" and "virtual" c/s rates as reported by "--test"
>> (on Unix-like operating systems)?
>> A: These correspond to real and virtual (processor) time, respectively.
>> The two results would differ when the system is under other load, with
>> the "virtual" c/s rate indicating roughly what you could expect to get
>> from the same machine if it were not loaded.
>> ... but this FAQ entry is outdated and needs to be revised.  As written,
>> it applies to single-threaded builds only (I wrote it before we
>> introduced OpenMP support).  Clearly, the numbers also differ greatly in
>> multi-threaded builds.  When running a multi-threaded build on an
>> otherwise idle system, the "real" speed will be roughly equal to the
>> "virtual" speed times the number of threads.
>> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ