Here's the first interesting part of a diff of the "objdump --disassemble" between two i386 kernels built from the same source within a few minutes of each other, but the one on the left was built on a native i386 machine and the one on the right was built on an amd64 machine (in a Xen domU), running netbsd-4 and netbsd-5 respectively: (everything before this appeared to just be differences in addresses (direct and indirect) of other objects, e.g. in mov or call instructions, etc.) 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 Then right away we're back in sync again except for address differences. There's a big diff further on that's a bit confusing to me. I'll just post the first few lines of each hunk because I'm not so sure that the disassembler didn't get confused here, though if it did then it soon got un-confused again: 38172,38335c38171,38332 < c011f5fa: 74 1a je c011f616 <ip_output+0x986> < c011f5fc: 8b 4d 94 mov -0x6c(%ebp),%ecx < c011f5ff: 31 d2 xor %edx,%edx < c011f601: 8b 81 60 01 00 00 mov 0x160(%ecx),%eax < c011f607: 89 d1 mov %edx,%ecx < c011f609: 25 80 00 00 00 and $0x80,%eax < c011f60e: 09 c1 or %eax,%ecx < c011f610: 0f 84 c7 03 00 00 je c011f9dd <ip_output+0xd4d> [[ .... ]] --- > c011f5fa: 74 10 je c011f60c <ip_output+0x97c> > c011f5fc: 8b 45 94 mov -0x6c(%ebp),%eax > c011f5ff: 80 b8 60 01 00 00 00 cmpb $0x0,0x160(%eax) > c011f606: 0f 89 d1 03 00 00 jns c011f9dd <ip_output+0xd4d> > c011f60c: f6 43 15 02 testb $0x2,0x15(%ebx) > c011f610: 8b 4d 94 mov -0x6c(%ebp),%ecx > c011f613: 8d 45 e0 lea -0x20(%ebp),%eax However it does sync up again soon with only diffs in addresses. Eventually we get to a change that really does seem to screw up the disassembler, though only for a short time: 126630,126634c126627,126631 < c016e7ad: 89 7c 24 0c mov %edi,0xc(%esp) < c016e7b1: 89 14 24 mov %edx,(%esp) < c016e7b4: 89 44 24 08 mov %eax,0x8(%esp) < c016e7b8: 8b 85 98 fe ff ff mov -0x168(%ebp),%eax < c016e7be: 89 44 24 04 mov %eax,0x4(%esp) --- > c016e7ad: 89 74 24 0c mov %esi,0xc(%esp) > c016e7b1: 89 7c 24 04 mov %edi,0x4(%esp) > c016e7b5: 89 44 24 08 mov %eax,0x8(%esp) > c016e7b9: 8b 85 5c fe ff ff mov -0x1a4(%ebp),%eax > c016e7bf: 89 04 24 mov %eax,(%esp) After this the diff eventually syncs up again until this curious out-of-order sequence with different register assignments: 172665,172669c172660,172664 < c0194ad5: 0f 84 7d 03 00 00 je c0194e58 <rf_AutoConfigureDisks+0x418> < c0194adb: c7 45 d4 00 00 00 00 movl $0x0,-0x2c(%ebp) < c0194ae2: 31 f6 xor %esi,%esi < c0194ae4: c7 45 d8 ff ff ff ff movl $0xffffffff,-0x28(%ebp) < c0194aeb: c7 45 dc ff 7f 00 00 movl $0x7fff,-0x24(%ebp) --- > c0194ad5: 0f 84 79 03 00 00 je c0194e54 <rf_AutoConfigureDisks+0x414> > c0194adb: 31 ff xor %edi,%edi > c0194add: c7 45 d0 ff ff ff ff movl $0xffffffff,-0x30(%ebp) > c0194ae4: c7 45 d4 ff 7f 00 00 movl $0x7fff,-0x2c(%ebp) > c0194aeb: c7 45 dc 00 00 00 00 movl $0x0,-0x24(%ebp) and on and on it goes.... -- Greg A. Woods Planix, Inc. <woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgplfw7NYBzfN.pgp
Description: PGP signature