At Mon, 27 Apr 2015 00:19:03 -0700, "Greg A. Woods" <woods%planix.ca@localhost> wrote:
Subject: Re: Xen-4.5 and NetBSD/amd64-7.99.5 won't start _my_ netbsd-5-X
>
> At Fri, 24 Apr 2015 14:56:06 -0700, "Greg A. Woods" <woods%planix.ca@localhost> wrote:
> Subject: Xen-4.5 and NeetBSD/amd64-7.99.5 won't start _my_ netbsd-5-X (was: false alarm!)
> >
> > I'm going to try a -current i386 kernel next. That's something I have
> > not yet tried.
>
> FYI my 7.99.9 i386 kernel, built on amd64 7.99.5, boots fine in Xen-4.5
>
> So, at least my Xen-4.5 servers can boot both "official" NetBSD-5-i386
> kernels and a locally built NetBSD-current-i386 kernels (as well as any
> NetBSD/amd64 kernel I've tried).
So just a belated update: The NetBSD-5/i386 kernel built on bare X86
hardware running NetBSD-4/i386 didn't boot a domU either.
See also my posts in port-i386 and/or tech-toolchain for some analysis
of the differences in objects compiled by the same (source) toolchain on
i386 and amd64.
Here's a kernel that boots fine:
ftp://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-5/201505270500Z/i386/binary/kernel/netbsd-XEN3PAE_DOMU.gz
So I built a kernel on the X86 machine with the extracted config file
from that working NetBSD-5 kernel, but my build would not boot either.
(BTW, "config -x" is useless to extract a usable config without
includes, and the output requires a lot of careful manual editing --
there should probably be a "config -X" that extracts a directly usable
config file with no dependencies!)
My build results in a _very_ different kernel from the official
(booting) kernel.
Now I do have some changes in my source tree that would account for
some, but not nearly all. This made me think the working nyftp kernel
was built on an amd64 host.
This time I disassembled the two kernels entirely and did a diff, and
all is effectively the same (except for absolute addresses) until we get
here (starting 2 instructions into rijndael_padDecrypt()).
I do have differences in my source tree as compared to what's being
built for nyftp, but nothing I can see that would cause any change in
rijndael-api-fst.c (even post-cpp) that could account for this:
6838,6859c6838,6857
< c01054d3: 83 ec 48 sub $0x48,%esp
< c01054d6: 89 7d fc mov %edi,-0x4(%ebp)
< c01054d9: 8b 7d 08 mov 0x8(%ebp),%edi
< c01054dc: 89 5d f4 mov %ebx,-0xc(%ebp)
< c01054df: 8b 45 14 mov 0x14(%ebp),%eax
< c01054e2: 89 75 f8 mov %esi,-0x8(%ebp)
< c01054e5: 8b 5d 10 mov 0x10(%ebp),%ebx
< c01054e8: 8b 75 0c mov 0xc(%ebp),%esi
< c01054eb: 85 ff test %edi,%edi
< c01054ed: 74 23 je c0105512 <rijndael_padDecrypt+0x42>
< c01054ef: 85 f6 test %esi,%esi
< c01054f1: 74 1f je c0105512 <rijndael_padDecrypt+0x42>
< c01054f3: 80 3e 00 cmpb $0x0,(%esi)
< c01054f6: 74 1a je c0105512 <rijndael_padDecrypt+0x42>
< c01054f8: 85 db test %ebx,%ebx
< c01054fa: 74 28 je c0105524 <rijndael_padDecrypt+0x54>
< c01054fc: 85 c0 test %eax,%eax
< c01054fe: 89 f6 mov %esi,%esi
< c0105500: 7e 22 jle c0105524 <rijndael_padDecrypt+0x54>
< c0105502: a8 0f test $0xf,%al
< c0105504: 74 22 je c0105528 <rijndael_padDecrypt+0x58>
< c0105506: b8 f8 ff ff ff mov $0xfffffff8,%eax
---
> c01054d3: 83 ec 68 sub $0x68,%esp
> c01054d6: 8b 55 18 mov 0x18(%ebp),%edx
> c01054d9: 89 75 f8 mov %esi,-0x8(%ebp)
> c01054dc: 8b 75 08 mov 0x8(%ebp),%esi
> c01054df: 89 5d f4 mov %ebx,-0xc(%ebp)
> c01054e2: 8b 45 14 mov 0x14(%ebp),%eax
> c01054e5: 89 7d fc mov %edi,-0x4(%ebp)
> c01054e8: 8b 5d 0c mov 0xc(%ebp),%ebx
> c01054eb: 89 55 bc mov %edx,-0x44(%ebp)
> c01054ee: 8b 7d 10 mov 0x10(%ebp),%edi
> c01054f1: 8b 15 20 19 47 c0 mov 0xc0471920,%edx
> c01054f7: 89 55 f0 mov %edx,-0x10(%ebp)
> c01054fa: 31 d2 xor %edx,%edx
> c01054fc: 85 f6 test %esi,%esi
> c01054fe: 74 22 je c0105522 <rijndael_padDecrypt+0x52>
> c0105500: 85 db test %ebx,%ebx
> c0105502: 74 1e je c0105522 <rijndael_padDecrypt+0x52>
> c0105504: 80 3b 00 cmpb $0x0,(%ebx)
> c0105507: 74 19 je c0105522 <rijndael_padDecrypt+0x52>
> c0105509: 85 ff test %edi,%edi
The instruction streams sync up again for a while, then there are other
differences, and so on.
Curiously this same first difference happens between the nyftp kernel
and my kernel, regardless of whether I build on i386 or amd64, so it
does suggest something different about my source tree, though I really
don't understand what it could be. The only local change in any header
that gets included is this one in <sys/param.h>:
-#define NVNODE (NPROC + NTEXT + 100)
+#define NVNODE ((NPROC + NTEXT + 100) * 4)
And as far as I can see that would not affect rijndael-api-fst.c in any way.
As I've noted on tech-toolchain, when I build on i386 and amd64, I get a
whole different set of differences, starting with:
10942,10959c10942,10958
< c0108937: 09 c1 or %eax,%ecx
< c0108939: 89 0e mov %ecx,(%esi)
< c010893b: 89 56 04 mov %edx,0x4(%esi)
< c010893e: a1 20 b0 47 c0 mov 0xc047b020,%eax
< c0108943: 01 c7 add %eax,%edi
< c0108945: ff 07 incl (%edi)
< c0108947: 83 c4 2c add $0x2c,%esp
< c010894a: 89 d8 mov %ebx,%eax
< c010894c: 5b pop %ebx
< c010894d: 5e pop %esi
< c010894e: 5f pop %edi
< c010894f: 5d pop %ebp
< c0108950: c3 ret
< c0108951: 7d 86 jge c01088d9 <crypto_newsession+0x69>
< c0108953: a8 02 test $0x2,%al
< c0108955: 0f 85 7e ff ff ff jne c01088d9 <crypto_newsession+0x69>
< c010895b: 90 nop
< c010895c: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
---
> c0108937: 89 0e mov %ecx,(%esi)
> c0108939: 89 56 04 mov %edx,0x4(%esi)
> c010893c: a1 20 b0 47 c0 mov 0xc047b020,%eax
> c0108941: 01 c7 add %eax,%edi
> c0108943: ff 07 incl (%edi)
> c0108945: 83 c4 2c add $0x2c,%esp
> c0108948: 89 d8 mov %ebx,%eax
> c010894a: 5b pop %ebx
> c010894b: 5e pop %esi
> c010894c: 5f pop %edi
> c010894d: 5d pop %ebp
> c010894e: c3 ret
> c010894f: 7d 88 jge c01088d9 <crypto_newsession+0x69>
> c0108951: a8 02 test $0x2,%al
> c0108953: 75 84 jne c01088d9 <crypto_newsession+0x69>
> c0108955: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
> c0108959: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpBMJoY2kNtI.pgp
Description: PGP signature