NetBSD Problem Report #58089

From Manuel.Bouyer@lip6.fr  Fri Mar 29 13:09:06 2024
Return-Path: <Manuel.Bouyer@lip6.fr>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E41BE1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 29 Mar 2024 13:09:06 +0000 (UTC)
Message-Id: <20240329130850.425A110373@armandeche.soc.lip6.fr>
Date: Fri, 29 Mar 2024 14:08:50 +0100 (CET)
From: Manuel.Bouyer@lip6.fr
Reply-To: Manuel.Bouyer@lip6.fr
To: gnats-bugs@NetBSD.org
Subject: MKREPRO isn't really reproductible
X-Send-Pr-Version: 3.95

>Number:         58089
>Category:       toolchain
>Synopsis:       MKREPRO isn't really reproductible
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 29 13:10:00 +0000 2024
>Last-Modified:  Sun Mar 31 06:25:01 +0000 2024
>Originator:     Manuel Bouyer
>Release:        NetBSD 10.0_RC6
>Organization:
>Environment:
System: NetBSD armandeche.soc.lip6.fr 10.0_RC2 NetBSD 10.0_RC2 (GENERIC_CAN) #12: Wed Jan 10 10:47:49 CET 2024 bouyer@armandeche.soc.lip6.fr:/local/armandeche1/tmp/build/amd64/obj/local/armandeche2/netbsd-10/src/sys/arch/amd64/compile/GENERIC_CAN amd64
Architecture: x86_64
Machine: amd64
>Description:
	Trying to reproduce an issue with kernel symbols under Xen,
	I tried to rebuild a i386 GENERIC kernel identical to
	http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/202403261910Z/i386/binary/kernel/netbsd-GENERIC.gz

	I did a cvs checkout using
	cvs co -r netbsd-10 -D "2024-03-26 19:10 UTC" -P src
	followed by
	./build.sh -m i386 -P tools kernel=GENERIC

	The resulting kernel show the same 'uname -a' output as the
	one from the official build, but they are still sighly different:
   text    data     bss     dec     hex filename
20198406         587900  745472 21531778        1488c82 netbsd-local
20198310         587900  745472 21531682        1488c22 netbsd-official

	And it seems related to debug_info:
netbsd-local:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for NetBSD 10.0, with debug_info, not stripped
netbsd-official: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for NetBSD 10.0, not stripped

	I didn't find how to build a kernel without debug_info

>How-To-Repeat:
	cvs co -r netbsd-10 -D "2024-03-26 19:10 UTC" -P src
	cd src && ./build.sh -m i386 -P tools kernel=GENERIC

	compare the resulting kernel with the one from the official
	202403261910Z build.
>Fix:


>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Manuel Bouyer <Manuel.Bouyer@lip6.fr>
Cc: gnats-bugs@netbsd.org, toolchain-manager@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: toolchain/58089: MKREPRO isn't really reproductible
Date: Fri, 29 Mar 2024 13:23:29 +0000

 > Date: Fri, 29 Mar 2024 13:10:00 +0000 (UTC)
 > From: Manuel Bouyer <Manuel.Bouyer@lip6.fr>
 >=20
 > 	cvs co -r netbsd-10 -D "2024-03-26 19:10 UTC" -P src
 > 	cd src && ./build.sh -m i386 -P tools kernel=3DGENERIC

 It looks like, for the i386 netbsd-10 autobuilds, we use:

 -P -x -N0 -V TMPDIR=3D/tmp -V BUILD=3Dyes -V MAKECONF=3D"${AB_HOME}/etc/mak=
 e.conf" -V MKDEBUG=3Dyes

 where ${AB_HOME}/etc/make.conf has (unnecessarily, I think):

 MKREPRO=3Dyes

 I have no idea what BUILD=3Dyes does, and it doesn't seem to be
 documented in share/mk/bsd.README (but it is _listed_ there and in
 BUILDING.mdoc), but -V MKDEBUG=3Dyes is probably the difference.

 We should have this information published somewhere so that others can
 verify it.

From: Robert Elz <kre@munnari.OZ.AU>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Manuel Bouyer <Manuel.Bouyer@lip6.fr>, gnats-bugs@netbsd.org,
        toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Subject: Re: toolchain/58089: MKREPRO isn't really reproductible
Date: Sat, 30 Mar 2024 09:13:58 +0700

     Date:        Fri, 29 Mar 2024 13:23:29 +0000
     From:        Taylor R Campbell <riastradh@NetBSD.org>
     Message-ID:  <20240329132330.E0F6F84D35@mail.netbsd.org>

   | I have no idea what BUILD=yes does, and it doesn't seem to be
   | documented in share/mk/bsd.README

 It is there in the version I have installed (which came from a 9.99.97
 build, almost 2 years ago, so isn't necessarily up to date)

 BUILD           If defined, 'make install' checks that the targets in the
                 source directories are up-to-date and remakes them if they
                 are out of date, instead of blindly trying to install
                 out of date or non-existent targets.

 I assume that the point of that is (or perhaps once was) so that it is
 possible to stick BUILD=yes (or BUILD=anything) in mk.conf and then simply
 do "make install" in any random source directory.

 I cannot imagine that that is relevant at all to users of build.sh
 which never (as best I can tell anyway) blindly does "make install"
 without actually building first (or not that I have ever seen happen,
 and I never set BUILD to anything).

 While I'm here, I cannot fathom why anyone trying to make a reproducible
 build would ever set MAKECONF to anything other than MAKECONF=/dev/null
 I do all builds that way, random settings in mk.conf (any random mk.conf)
 are rarely conducive to productive builds.   Any build variations I need
 go on the command line, not there.   A reproducible build should have none.

   | (but it is _listed_ there and in
   | BUILDING.mdoc), but -V MKDEBUG=yes is probably the difference.

 Something related to DEBUG probably is, but it most likely is not exactly
 that.   Manuel's build did not include that option, and yet the difference
 he showed had some debug related info in the netbsd kernel he built, which
 was not there in the downloaded version (not a lot apparently, as the kernel
 he ended up with was a whole 96 bytes bigger (file size, the loadable segments
 were the same size) than the one he downloaded.

 Manuel, check your mk.conf (or build without using it as above) and see
 if there's anything there - also check that you had no .o files in the
 kernel obj directory from some earlier build, which may have had MKDEBUG
 set.

 kre


From: Andreas Gustafsson <gson@gson.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Manuel Bouyer <Manuel.Bouyer@lip6.fr>,
    gnats-bugs@netbsd.org,
    toolchain-manager@netbsd.org,
    gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: Re: toolchain/58089: MKREPRO isn't really reproductible
Date: Sat, 30 Mar 2024 12:39:48 +0200

 Taylor R Campbell wrote:
 > We should have this information published somewhere so that others can
 > verify it.

 See also PR 54544.
 -- 
 Andreas Gustafsson, gson@gson.org

From: Manuel Bouyer <manuel.bouyer@lip6.fr>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@netbsd.org, toolchain-manager@netbsd.org,
        gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: toolchain/58089: MKREPRO isn't really reproductible
Date: Sun, 31 Mar 2024 08:19:45 +0200

 On Fri, Mar 29, 2024 at 01:23:29PM +0000, Taylor R Campbell wrote:
 > > Date: Fri, 29 Mar 2024 13:10:00 +0000 (UTC)
 > > From: Manuel Bouyer <Manuel.Bouyer@lip6.fr>
 > > 
 > > 	cvs co -r netbsd-10 -D "2024-03-26 19:10 UTC" -P src
 > > 	cd src && ./build.sh -m i386 -P tools kernel=GENERIC
 > 
 > It looks like, for the i386 netbsd-10 autobuilds, we use:
 > 
 > -P -x -N0 -V TMPDIR=/tmp -V BUILD=yes -V MAKECONF="${AB_HOME}/etc/make.conf" -V MKDEBUG=yes
 > 
 > where ${AB_HOME}/etc/make.conf has (unnecessarily, I think):
 > 
 > MKREPRO=yes
 > 
 > I have no idea what BUILD=yes does, and it doesn't seem to be
 > documented in share/mk/bsd.README (but it is _listed_ there and in
 > BUILDING.mdoc), but -V MKDEBUG=yes is probably the difference.
 > 
 > We should have this information published somewhere so that others can
 > verify it.

 Thanks. Indeed with MKDEBUG=yes the kernel doens't have debug_info
 (it's counterintuitive :)
 BUILD=yes doens't seem to change anything for the kernel.

 There is still a difference of 96 bytes between my kernel and the
 official one. strings(1) shows this which may be relevant:
 -_CFG_### START CONFIG FILE "/local/armandeche2/netbsd-10-20240326/src/sys/arch/i386/conf/GENERIC"
 +_CFG_### START CONFIG FILE "GENERIC"

 I didn't find how config(1) could generate a config_file.h without absolute
 path.

 -- 
 Manuel Bouyer, LIP6, Sorbonne Université.           Manuel.Bouyer@lip6.fr
      NetBSD: 26 ans d'experience feront toujours la difference
 --

Home	PR Database Search