Dear all,
I've prepared a OpenSSL 1.0.2j import for current, but have a few things
to resolve that I need help with:
- the new sha1 asm for x86_64 doesn't work, it throws illegal instruction
in SHA1_Update and that impacts quite a few crypto mechanisms.
We can skip asm sha1 for now, but this
Just to clarify:
> http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD.diff.xz
does not try to use
src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha1-x86_64.S
for amd64. To enable using it, edit
src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha.inc by
moving the #if 0 down. W
Thus wrote S.P.Zeidler (s...@netbsd.org):
> - the new sha1 asm for x86_64 doesn't work, [...]
Thanks to Christos this part is fixed.
I still need verifications from non-x86 :)
regards,
spz
On 2016/10/09 6:29, S.P.Zeidler wrote:
I still need verifications from non-x86 :)
I tried it on powerpc boxes. Since build fails with your original patch,
I added some corrections. Please find the attached notes and patch. With
my patch, all 29 tests (MKCRYPTO_RC5=yes) in /usr/tests/crypto/libc
Thus wrote Rin Okuyama (rokuy...@rk.phys.keio.ac.jp):
> On 2016/10/09 6:29, S.P.Zeidler wrote:
> >I still need verifications from non-x86 :)
>
> I tried it on powerpc boxes. Since build fails with your original patch,
> I added some corrections. Please find the attached notes and patch. With
> my
On 2016/10/12 7:37, S.P.Zeidler wrote:
I added your patch (with two modifications, see below) plus fixes that
make i386 and sparc* compile (and fix i386, which is tested) into my
changes and created a new diff from it:
http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz
Thank you for re
On 2016/10/12 7:37, S.P.Zeidler wrote:
I added your patch (with two modifications, see below) plus fixes that
make i386 and sparc* compile (and fix i386, which is tested) into my
changes and created a new diff from it:
http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz
I also tested it
On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote:
> I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP
> kernel from sparc64 and userland from sparc) version passed the 29 tests
> in /usr/tests/crypto/libcrypto.
The sparc64 tests work for me too, but sparc on 32bit
Thus wrote Martin Husemann (mar...@duskware.de):
> On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote:
> > I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP
> > kernel from sparc64 and userland from sparc) version passed the 29 tests
> > in /usr/tests/crypto/libcryp
On 2016/10/13 3:16, S.P.Zeidler wrote:
# Some .S files in arch/sparc* are generated but not used. Is this OK?
That's mostly me being a completionist. Makes working on checking if they
have an advantage and activating them if yes at a later date easier.
OK, I understand. I agree with your stra
On Wed, Oct 12, 2016 at 08:16:37PM +0200, S.P.Zeidler wrote:
> Thus wrote Martin Husemann (mar...@duskware.de):
>
> > On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote:
> > > I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP
> > > kernel from sparc64 and userland f
On 2016/10/13 4:02, Rin Okuyama wrote:
On 2016/10/13 3:16, S.P.Zeidler wrote:
If you don't use an ASM method it should fall back to C and that should
always work, just be a bit slower, and most of the ASM in sparc only kicks
in if MACHINE is sparc64.
Ah, I've realized the situation at last (I'
On Fri, Oct 14, 2016 at 03:45:02AM +0900, Rin Okuyama wrote:
> Oops, the combination of MACHINE_ARCH == sparc && MACHINE == sparc64 is
> rejected by build.sh. When do it forcibly, compile errors occur here and
> there. ".if ${MACHINE} == sparc64" in somewhere/arch/sparc is paraphrase
> of ".ifdef n
On 2016/10/14 16:24, Martin Husemann wrote:
I'm a bit confused what you are trying to do. We support v9 (or v8plus)
machines only with sparc64 kernels (and the sparc SUN4U kernel is just
a 32bit sparc64 kernel actually).
You can then run (as you did) either sparc64 (v9, 64bit) userland or
plain
14 matches
Mail list logo
