At Thu, 30 Apr 2015 11:40:03 -0400, I wrote:
Subject: Re: worrying differences in object code due to different build host!
>
> Historically there has never been anything but instructions and maybe
> a few data bytes in the .text section, and I would expect the same
> compiler to generate the exact same .text (and .data) sections from the
> same source code no matter when or where it is run. I would expect any
> differences from the build environment to only show up in other sections.
So, here's where part of my problem began....
It appears there's been a convention in the binutils world to include
the .rodata section in with .text when reporting in "Berkeley" format.
If one asks for the "SysV" format (or uses the '-A' flag), then one sees
the .rodata section reported separately.
I wish I'd known/remembered that before.
Indeed as Martin suggested there are different pathnames to the source
tree depending on whether it is local or mounted via NFS on my different
build machines, and the compiler inserts a .string with source file's
pathname in the .rodata section.
However, that's not the whole story.
I modified the makeoptions in the kernel config file in order to ask the
compiler to generate a .list file for every source file:
makeoptions CPUFLAGS="-march=i686 -Wa,-acdlns=${@:R}.list"
The differences between the .list files built on the NetBSD/amd64
-current and 5.2_STABLE machines were, for the most part uninteresting
(with almost all differences having to do with the .rodata section).
There were only two files differing in ways that my inexperience with
modern x86 assembler leaves me wondering what is going on (see below).
However the kernel built by the NetBSD/i386-4.0_STABLE machine is indeed
radically different in quite a few, but not all, files -- but the files
which were different on the -current and 5.2_STABLE build hosts were
nearly identical between the i386-4.0 and amd64-5.2 hosts, with the
amd64-current build host being the odd one out and generating the
different code.
Here you'll see the real .text does differ in size, while the .rodata
has the same size due to having identical NFS mount paths for the source
trees on each build host:
/nbsd-current-build/netbsd-5-amd64-i386-ppro-obj/.../netbsd :
section size addr
.text 3083564 3222274048
.rodata 426115 3225357632
link_set_malloc_types 224 3225783748
link_set_sysctl_funcs 248 3225783972
link_set_domains 32 3225784220
link_set_pools 104 3225784252
link_set_modules 72 3225784356
link_set_evcnts 28 3225784428
link_set_dkwedge_methods 8 3225784456
link_set_bufq_strats 12 3225784464
.data 65924 3225788608
.bss 470484 3225858048
.note.netbsd.ident 24 3226328532
.ident 44699 0
__xen_guest 195 0
.comment 46190 0
.debug_abbrev 597 0
.debug_info 24547 0
.debug_line 1303 0
.debug_frame 44 0
.debug_loc 44 0
.debug_pubnames 106 0
.debug_aranges 32 0
.debug_str 13006 0
Total 4177602
/nbsd-4.0-build/netbsd-5-i386-i386-ppro-obj/.../netbsd :
section size addr
.text 3084364 3222274048
.rodata 426115 3225358432
link_set_malloc_types 224 3225784548
link_set_sysctl_funcs 248 3225784772
link_set_domains 32 3225785020
link_set_pools 104 3225785052
link_set_modules 72 3225785156
link_set_evcnts 28 3225785228
link_set_dkwedge_methods 8 3225785256
link_set_bufq_strats 12 3225785264
.data 65924 3225789376
.bss 470484 3225858048
.note.netbsd.ident 24 3226328532
.ident 44699 0
__xen_guest 195 0
.comment 46190 0
.debug_abbrev 597 0
.debug_info 24547 0
.debug_line 1305 0
.debug_frame 44 0
.debug_loc 44 0
.debug_pubnames 106 0
.debug_aranges 32 0
.debug_str 13008 0
Total 4178406
Now I have to wonder if there are any bugs in the amd64-hosted builds
for i386. I sure don't trust something any more, but I don't know what!
(especially since the i386-host-built Xen kernel didn't run either)
It may explain a more -- I had no luck booting a non-Xen test i386
kernel some time ago under VirtualBox. At the time I simply gave up and
assumed a VB bug because I was more concerned with getting the Xen
servers running, and I wasn't having any trouble booting them with new
amd64 kernels.
So now I guess I need to upgrade my old i386 machine with its own
bootstrapped build and see what the 5.2 cross-compiler built on an
i386-5.2 machine does. I know the 4.0 machine can cross-compile a
working i386-5.2 system, as that's how I got the amd64 machines running
in the first place. Or maybe I still have a bootable i386 VB image...
Here are the diffs for ibcs2_misc.list, and similar differences are
found in svr4_misc.list as well:
The first file, on the left, was built on the -current host and the
second file, on the right, was built on the 5.2_STABLE host. For
context, this code is in the ibcs2_sys_getdents() function. If anyone
wants full copies of the differing .list files, let me know!
2696c2696
< 2508 152f 899DD0FD movl %ebx,-560(%ebp)
---
> 2508 152f 899DD4FD movl %ebx,-556(%ebp)
2700c2700
< 2510 153b 8D85D8FD leal -552(%ebp),%eax
---
> 2510 153b 8D85DCFD leal -548(%ebp),%eax
2715c2715
< 2520 1565 8B85D8FD movl -552(%ebp),%eax
---
> 2520 1565 8B85DCFD movl -548(%ebp),%eax
2787c2787
< 2567 1624 8B85D8FD movl -552(%ebp),%eax
---
> 2567 1624 8B85DCFD movl -548(%ebp),%eax
2832c2832
< 2592 16a3 8D85D0FD leal -560(%ebp),%eax
---
> 2592 16a3 8D85D4FD leal -556(%ebp),%eax
2835c2835
< 2594 16ad 8B85D8FD movl -552(%ebp),%eax
---
> 2594 16ad 8B85DCFD movl -548(%ebp),%eax
2837c2837
< 2595 16b3 8D8DDCFD leal -548(%ebp),%ecx
---
> 2595 16b3 8D8DD0FD leal -560(%ebp),%ecx
2839c2839
< 2596 16b9 8D95D4FD leal -556(%ebp),%edx
---
> 2596 16b9 8D95D8FD leal -552(%ebp),%edx
2876c2876
< 2619 172a 8B85D0FD movl -560(%ebp),%eax
---
> 2619 172a 8B85D4FD movl -556(%ebp),%eax
3043c3043
< 2725 18fa 8B85D0FD movl -560(%ebp),%eax
---
> 2725 18fa 8B85D4FD movl -556(%ebp),%eax
3056c3056
< 2735 1917 89B5D0FD movl %esi,-560(%ebp)
---
> 2735 1917 89B5D4FD movl %esi,-556(%ebp)
3074c3074
< 2746 1942 8B85D8FD movl -552(%ebp),%eax
---
> 2746 1942 8B85DCFD movl -548(%ebp),%eax
3096c3096
< 2762 197a 8B85D0FD movl -560(%ebp),%eax
---
> 2762 197a 8B85D4FD movl -556(%ebp),%eax
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpnWjpckNUHr.pgp
Description: PGP signature