[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20150526060150.dc30d64f61e5ec441c34ffd4f788e58e.fdf7a129c8.wbe@email15.secureserver.net>
Date: Tue, 26 May 2015 06:01:50 -0700
From: <writeonce@...ipix.org>
To: john-dev@...ts.openwall.com
Cc: "Rich Felker" <dalias@...c.org>
Subject: RE: update: JtR for Windows using musl libc
On 05/26/2015 02:14 AM, Solar Designer wrote:> On Mon, May 25, 2015 at
10:19:17PM -0700, writeonce@...ipix.org wrote:
>> I have now looked at x86-64.h and DES_bs.h and have added a few sysv_abi
>> hints which did not change the outcome. My understanding is that someone
>> familiar with JtR would have an easier time debugging this.
>
> Yes, but we don't have your setup ready for debugging on. And many of
> us don't have Windows.
>
> Can you try building for -avx? The issue should be gone then (in that
> build), as that disables use of the assembly code.
>
>> As for performance: at some point I commented out the code in times(2)
>> which converts NT measures (units of 100ns) to clock_t (1/100 sec)...
>> the test was run natively on i3-2100 pc, and with the fixed __sys_times
>> the numbers now finally seem correct. As an aside, an additional factor
>> that might slow things down a bit (but nothing like *100000) is that the
>> entire stack (libc, runtime library, john) is built with -g3 -O0.
>
> Yes, the speeds look sane now, and clearly those with no assembly code
> are impacted by -O0 a lot.
>
> One thing that is still unclear to me is why you have a 2x gap between
> real and virtual times. It looks like the virtual times are doubled,
> much like they would be when running 2 threads, but I think you are not
> (the DES code in x86-64.S isn't even thread-safe). So I am puzzled.
>
> Alexander
>
>
Built with -avx, john almost always terminates abnormally in the middle
of the tripcode test. Since this behavior is inconsistent and goes away
with debugging I suspect the problem is in the runtime library and am
currently working to find it.
Regarding the gap between real and virtual times: __sys_times had it
wrong again, making a distinction between current thread and current
process, rather than current process and current process and all
children. While the multithreaded behavior you identified could have
been related to the runtime's internal threads, the perfect x2 factor is
too pretty to make that the sole explanation. In case that helps, the
previous (buggy) implementation of times(2) can be found at
http://midipix.org/scrap/__sys_times
midipix
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.
