From nobody Tue Feb 21 23:54:26 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PLx3Q2PwCz3tff6 for ; Tue, 21 Feb 2023 23:54:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PLx3P1bY0z4Y4y for ; Tue, 21 Feb 2023 23:54:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CUIg48JT; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677023679; bh=i3GuVgakRYBTFgm2pBNp0vb7YhzcGn5OfUX1McQTrek=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CUIg48JTl3tjhH5z537LtjAy9Pn3cI7ORu5uANHocRrVf0J73r5q6TgtEONB/b7nTAaqbKyP/6y0gYDb0k5YiZ8SVYv0Hoe5at3Z31jP3kaJBXyA3YR+16u6h91muoUEDfq8IYonCN47rg4OJ4qHlMtTd6cByrHBMi5RlpkfU/oo4QRcDPQNOQsMWNoFnao/23IUsdT1hZjTGwyen9Pdjpj1d0PUVTfyvLzB+enDEHxKXh+uDNBMxco3B6AZxFxTLhPVb2blsCjUFU80CCa8kMKfQmIkJyqpwqwBUHKKznCLljDFlbGNZefLsNwGons5uA1vIVtRyBR35q7nfo8j6A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677023679; bh=EvTSOCjB3o+phwHamYG++yYXQ5lmBJnkg5SylNDu043=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dQmJX75sfMa9QTExXJ1jla1/RicYusOScRpTjbu9xhmyknzRNOb6seI2XTYyxEKfd7eawQ+UbPXo8Nw8kTShf9f/vj1h1MK7Bh5MRfroYgsllR8Zm3Tix7E2wPZpH7asfDIe3z2GoV/1q7ZP+wcPS8rxIsgHMEIE5WgT3XZeFTwM47enJIAlvlx/V/+Bf4vXtlVLKevk88O0lp7YRoat02FLsULTd1Qv32RwT89BQAeR7I/XG+OJBM9lvlSWvVysqJkWgLxIUoEbnS2lvCrFtclgZsX8nXdB7jHrMjHSq8cMFEDVz50ovidPoMtALGPNWnNcr5Qt//2jkaeTBYGJhg== X-YMail-OSG: okUfYBkVM1nFb0OcQ90oCVWsxFMJJ2eH1eRl2H0tflo.2Z4fxwdOdL2_SZAn0Pa lnkqOZWH_WyCatpG8y9Q7bm8M2y8jz8GQyuZy2ETgBsmgl7H7yD7a7K.2VRu0HPw.fl1Q6z_UcRh Jnh7lgVk2xcf7XhBZ5akPx1..xWAQRPv5zOqjtoBZ3re_HV_O_NWTA8llj5dchPxESE1oYVlrzti srvpsRmqMtwaVATVnjAP3Ggf1pQhP9R4kouUwVxi9d29uwkDiFYQOmoRqmuLuJzlmry58Nlh4Gqm JdQHRPwT1kKSdCwoMYcG6FuZGrRHhh2vCT0Umw_zNDk3svoEcEYyymoO1IdXytv1MG.3H4LzIlmJ SHMvinT8U1sm_PU7qFceIyuuaF7swJQ3vM23dDpz3dDWWwJ1pHKE6UUzZ20IXcklUPm8HEBnQ5MJ pAd9yp4l5z.6L4FolChzw._9p0P8hZhzcI_83oubP8wYNc6OQTcwTKKLPnSqN47MDo6rWXG6Umsm 10pQMRoR7JXWNZ8FjtTkdMW1oFFjM.3WDkPB35mhxIiTZNNDH.UFRAhqkW.zX5m4A3gnZDqXH5BY yKAh9_SePCMubrzIfegbrqTmjJq6A8I.RpNmERm6aVMaI7iWEoVhPnktOvQsW52.AJU5WSkp6bNR JJxOJSCQ5iYwMrl0CIsoXUhrxAnM33VDFcnzg7TH5Xi5CsEQ.E0kyfl7etPqSSzggxkYqIl0jewE dMDWdbjpvoScWzrw1Jmp8E.65KPEYS7kqvIci0wNRBE8bYHnIYhcslEyWjvAX.cnJFch_LB1njA0 i8qmLSPQucD3Z0chd64_Tr3cS_jjvTR6ziDCBTlDX9lBtrBFaQYnjGQiXItWmSUcYDIyM8oG6nVX R6NQeOBmA73ckIEi2nNQHaYHegSsikbqzeMd7XV0FSC46ntX8J4JGaI9bbI86LoSC2a1QG38h1mt gVJq_k0Upi7deW3onYb3rbMLA9pSZ3Ob9mse3fapxQ53Qdqpbp1p3VqzDoMZNdLsX.fdcb1zoaIo RiwvQ8LSewB6cGraZzcdYaH0L1k5QAjR14QYQS1eO_b.zgKnrnTF0CDz9o8jVrAUoL5SVShEKsIs FSqXIT2EJOgB4rAUtwNnOaL1wpQkuspojmEcG4GB_CysmeSiO1KCw39cdnrSahwbCIMIfPB1PSBD I5vB4L5gLp6qTyih5aBOfV6AHJZkCCOi58IwauDTrR.Mqto.ziXkxl4NCShpCGjjWbNHSDd989MS fggpaqhU.uSzhe7tqwnZ9OdrY8mhHNRqEsQU5nPdmEixSPtiRIue_7FU_Vo46nwp091OD3h2Q7xw m3FlBMS6biEYKe0h5SYf0XEY9n882Smz9Ei9RtJHzdQ7tAXsSUqSLnaUvLvunrGVV1XmWfYEqXtD R_OPqg1KsvXY1W4kxn_ALqKF9ljp28eUwl5Zd4DvC9og7GZNBjZvQ6c8x4vWV8xoUzP8HPcVa4Nq sJWCIaIN.szikOR90Fx97txx7xCLI0Pf3H7W98hUnQ16wHGP7gLdYyXDQQFCtD8QOK2AwGoMa7Xg isrMbG5QM.ZANv_O5XtxsqCu40VyucAHNuQT7iJytvlO9aVYX_aA.cVV_X.iFJ3Le0Y0pkBWHRF. 0lR9pFFS5DY5Fowi1oe.cZzc35sM1PhOvZmXj3issvgdh6Br3dK0QpWLKf9hWHoI.t0zpL5taK19 0IOu0siQF7mTSC_qHuGI4eBIWkuPfcTL8AZ1CzQYUP45QtRisoxI0I5wtyIyJtCcdX9R5fhQFGwm OLR2gRtX3XMua.ZOIa1x6SgZn6uvmGHXzVKdJ51E4UJB.9ojnUjsU6_9Me.aFzp9FE3cWpbgzWol 6A2W.1GIAt1y8mVdE2NCr76ABp61GJQk40bIaAEmq65ppqBojZxta5OhqMHeiHH4Qu0seEsBBaty xeZV.ozpy44uhIjEEu5QC6lcoRcDgDNz2_OKm1nnydpNjr4LupboDWUNI_vRejiDKqOALnkzButz 5cxzej8JgnzPWcCL4r8BIS319525W7dC9LeeZJV_Qdo29QnjrVVgG3NZ.6hIL2EY1tVhtV_rKYl1 FFTBthie49gE8fd4fMlz7kpchOP3yL82nzfbHP8GWBW67NdE_NppFU7r6F11gOx.ixIW3FYT.cn1 2JZ4xsNgmWmH3uv.xEqGE.OPUdwA.X9kjjAapmNfd5FPmxgeGrSc.T6HyH_HHtGh5yBLRghGY_0U M8BFeHlm7c1nIxfa0ETIF95FMoWdDiInk3BvBYHPRCvwGQutU4nxPGXlJ1VGbZiACwNydjBOW.TA M X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Feb 2023 23:54:39 +0000 Received: by hermes--production-gq1-655ddccc9-l45xf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 20cdc9035b43667e19d9c3d889ac6ae1; Tue, 21 Feb 2023 23:54:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: 13.2 BETA2: how do debug META_MODE? From: Mark Millard In-Reply-To: Date: Tue, 21 Feb 2023 15:54:26 -0800 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <41B536B0-DA66-449E-96BB-E11A8750471A.ref@yahoo.com> <41B536B0-DA66-449E-96BB-E11A8750471A@yahoo.com> To: Peter X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.46 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.958]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org] X-Rspamd-Queue-Id: 4PLx3P1bY0z4Y4y X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Feb 21, 2023, at 11:56, Mark Millard wrote: > On Feb 21, 2023, at 04:55, Peter wrote: >=20 >> On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote: >> ! Peter wrote on >> ! Date: Tue, 21 Feb 2023 03:45:12 UTC : >> !=20 >> ! > on /some/ of my nodes, META_MODE seems not being honored anymore: >> ! > I had to build them another time, and the lengthy lib/clang gets >> ! > built all over again (tried two times). >> ! > This is so since 13.2 (BETA2). It did work in 13.1 (RELENG), at = least >> ! > according to the timing from the logfiles.=20 >> ! >=20 >> ! > Now I'm trying to figure out the difference, because I have some >> ! > nodes where it appears to more-or-less work (have seen buildworld >> ! > take 5 minutes), and others where it doesn't (take an hour to = build). >> ! > The thing is scripted, so it is not so very likely an operator = error >> ! > (while not impossible either). >> ! >=20 >> ! > But it seems difficult to figure out details: "make -n" seems to = not >> ! > care about META_MODE, while META_MODE suppresses all useful = output from >> ! > make. And the docs say there are *.meta files (yes there are), = but no >> ! > info about how to verify their content, or how to get make tell = what >> ! > it is going to do and why (and the buildworld is not the most = easy >> ! > to understand target)... >> ! >=20 >> ! > So, some inspiration would be welcome... >> !=20 >> ! On thing to check on is if filemon.ko is loaded and operational. >> ! META_MODE greatly depends on it. >>=20 >> That should be the case - 'kldstat' shows it (and I've seen warnings >> where it didn't). >>=20 >> ! Another thing to know is that the following are very different >> ! for what all is built for the "(again #0)" line vs. the other >> ! two "again" lines, using buildworld as an example context. >> ! Imagine here the the first buildworld rebuilds llvm/clang >> ! materials. >> !=20 >> ! # cd /usr/src/ >> ! # env WITH_META_MODE=3Dyes make buildworld >> ! # env WITH_META_MODE=3Dyes make installworld >> ! # env WITH_META_MODE=3Dyes make buildworld (again #0) >> ! ## no more rebuilds below? >> ! # env WITH_META_MODE=3Dyes make buildworld (again #1) >> ! # env WITH_META_MODE=3Dyes make buildworld (again #2) >>=20 >> But what is the difference between #0 and #1? >=20 > awk, cp, ln, rm, sed, and many more from > . . ./tmp/legacy/usr/sbin/have new dates > for rebuilds after installworld (that targets > the running system). Not true for #1 and #2. >=20 > The dates on these tools being more recent than > the files that they were involved in producing > leads to rebuilding those files. That in turn > leads to other files being rebuilt. >=20 > make with -dM reports the likes of: >=20 > file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target... >=20 > explicitly as it goes. As I remember tmp/legacy/usr/sbin/ > was always part of the path for what I found. >=20 > One still has to trace back to were rebuild a rebuild > is not due to something rebuilt in earlier in the same > build. Noting that tmp/legacy/usr/sbin/awk is reported > as newer than its target, leaves the question of how > it ended up being newer: earlier in same build vs. > before build activity? It too must be traced back > to something based on just material from prior to > the build in question. >=20 > Note that the above make sequence was only intended > for showing the dependency, not as instructions for a > normal update sequence. >=20 >> . . . >>=20 >> ! See: >> !=20 >> ! = https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.ht= ml >=20 > This (and later messages in the thread) are about the > "awk, cp, ln, rm, sed, and many more" that make with -dM > explicitly reports (likely from tmp/legacy/usr/sbin/ ). > If you trust the make date comparisons, it is the easiest > way to find out what has "is newer than the target" status > that leads to starting a rebuild sequence. (Other dependent > things then rebuild based on this rebuild. One still has > to trace back to where things start.) >=20 > I did not do the analysis of how (e.g.) tmp/legacy/usr/sbin/awk > ended up being newer than such a target and, so, causing a > rebuild of that target. I was going the direction: that > it is newer really is unlikely to justify the rebuild for > the target(s) in question. The other direction about how > it got to be newer is also relevant. Using awk as an example, for the (re)build of awk in: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/ in my context, here is a list of files that installworld installs that contribute to the build (and a couple of "Fork" lines): (from = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awk.full.meta ) E 51580 /bin/sh R 51580 /etc/libmap.conf R 51580 /usr/local/etc/libmap.d R 51580 /usr/local/etc/libmap.d/mesa.conf R 51580 /var/run/ld-elf.so.hints R 51580 /lib/libedit.so.8 R 51580 /lib/libc.so.7 R 51580 /lib/libtinfow.so.9 R 51580 /usr/share/locale/C.UTF-8/LC_CTYPE F 51580 51585 E 51585 /usr/bin/cc R 51585 /etc/libmap.conf R 51585 /usr/local/etc/libmap.d R 51585 /usr/local/etc/libmap.d/mesa.conf R 51585 /var/run/ld-elf.so.hints R 51585 /lib/libz.so.6 R 51585 /usr/lib/libexecinfo.so.1 R 51585 /lib/libncursesw.so.9 R 51585 /lib/libtinfow.so.9 R 51585 /lib/libthr.so.3 R 51585 /lib/libc++.so.1 R 51585 /lib/libcxxrt.so.1 R 51585 /lib/libm.so.5 R 51585 /lib/libc.so.7 R 51585 /lib/libelf.so.2 R 51585 /lib/libgcc_s.so.1 F 51585 51607 E 51607 /usr/bin/ld R 51607 /etc/libmap.conf R 51607 /usr/local/etc/libmap.d R 51607 /usr/local/etc/libmap.d/mesa.conf R 51607 /var/run/ld-elf.so.hints R 51607 /usr/lib/libexecinfo.so.1 R 51607 /lib/libtinfow.so.9 R 51607 /lib/libz.so.6 R 51607 /lib/libthr.so.3 R 51607 /lib/libc++.so.1 R 51607 /lib/libcxxrt.so.1 R 51607 /lib/libm.so.5 R 51607 /lib/libc.so.7 R 51607 /lib/libelf.so.2 R 51607 /lib/libgcc_s.so.1 So, any of those getting new dates are examples of how installworld can lead to the following buildworld creating an updated (installation place): = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/awk ( sbin/ is really a symbolic link to ../bin/ ). That in turn leads to various other things being rebuilt that had awk involved. (This was a partial summary as, for example, there could be local .o files involved with dependencies not noted above but that contribute to whatever example program is picked.) >> !=20 >> ! and: >> !=20 >> ! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257616 . >>=20 >> Thank You, that's exactly the inspiration I was looking for! >> Diving back in... >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com