PR/57241 CVS commit: [netbsd-11] src

["Martin Husemann" <martin%netbsd.org@localhost>]

The following reply was made to PR toolchain/57241; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/57241 CVS commit: [netbsd-11] src
Date: Fri, 9 Oct 2026 15:09:02 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Fri Oct  9 15:09:02 UTC 2026
 
 Modified Files:
 	src/libexec/ld.elf_so [netbsd-11]: Makefile
 	src/share/mk [netbsd-11]: bsd.kmodule.mk bsd.lib.mk bsd.prog.mk
 	src/tests/lib/csu [netbsd-11]: Makefile
 	src/tests/libexec/ld.elf_so [netbsd-11]: Makefile
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #514):
 
 	share/mk/bsd.prog.mk: revision 1.360
 	share/mk/bsd.lib.mk: revision 1.424
 	share/mk/bsd.prog.mk: revision 1.361
 	tests/libexec/ld.elf_so/Makefile: revision 1.33
 	tests/lib/csu/Makefile: revision 1.14
 	share/mk/bsd.kmodule.mk: revision 1.87
 	share/mk/bsd.kmodule.mk: revision 1.88
 	libexec/ld.elf_so/Makefile: revision 1.152
 
 bsd.prog.mk: Fix parallel builds of debug data.
 
 Previously, we had one rule to generate foo, and another rule to
 derive foo.debug from it with objcopy -- and then rewrite foo _in
 place_ to strip the debug data with objcopy.
 
 This is wrong -- one rule should never overwrite another rule's
 target; this violates the contract with make(1), and can lead it to
 run rules in parallel on files that are changing, which in turn can
 lead the rules to behave mysteriously or crash.
 
 It's still not clear why in our autobuilds, the only cases where we
 saw these crashes were in mips64 builds of programs that use
 compat/exec.mk (mainly external/bsd/ipf/bin/ipftest, but also
 usr.sbin/crash and usr.bin/systat).  But the bug this change fixes is
 well-understood, and now someone has observed it in a non-mips build,
 so I'm throwing in the towel on figuring out what makes these
 particular programs more likely to trigger the problem.
 
 PR toolchain/57241: mips64el--netbsd-install core dumps randomly
 
 bsd.kmodule.mk: Fix parallelism in debug data generation recipes.
 
 In the recipe for foo.kmod.debug, don't overwrite foo.kmod in place.
 
 Instead, generate foo.kmod.link with debug data included, and then
 derive foo.kmod (no debug data) and foo.kmod.debug (only debug data)
 from it in separate recipes.
 
 Same issue as we had with bsd.lib.mk and bsd.prog.mk in the past.
 
 PR toolchain/57241: mips64el--netbsd-install core dumps randomly
 tests/lib/csu, tests/libexec/ld.elf_so: Apply CTFMERGE=: workaround.
 
 The workaround for
 PR toolchain/59364: ctf tools needs update
 required an update after fixing
 PR toolchain/57241: mips64el--netbsd-install core dumps randomly
 by splitting the recipes for ${PROG} and ${PROG}.debug into an
 intermediate ${PROG}.link to avoid overwriting ${PROG} inside the
 recipe for ${PROG}.debug.
 
 This is kludgey (writing the `.link' suffix into a Makefile isn't
 great) but I see only two cases of it so this'll do for now.
 bsd.*.mk: Use objcopy without -p to strip debug data.
 
 No need to preserve the date with -p/--preserve-dates -- the only
 meaningful effect it has is to cause make(1) to rerun it every time,
 because make(1) treats exactly the same date as out-of-date.
 
 Followup after:
 PR toolchain/57241: mips64el--netbsd-install core dumps randomly
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.151.2.2 -r1.151.2.3 src/libexec/ld.elf_so/Makefile
 cvs rdiff -u -r1.86 -r1.86.4.1 src/share/mk/bsd.kmodule.mk
 cvs rdiff -u -r1.419.2.2 -r1.419.2.3 src/share/mk/bsd.lib.mk
 cvs rdiff -u -r1.356.2.2 -r1.356.2.3 src/share/mk/bsd.prog.mk
 cvs rdiff -u -r1.12 -r1.12.2.1 src/tests/lib/csu/Makefile
 cvs rdiff -u -r1.28.2.4 -r1.28.2.5 src/tests/libexec/ld.elf_so/Makefile
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.