Re: 13.2 BETA2: how do debug META_MODE?

On Feb 21, 2023, at 11:56, Mark Millard <marklmi@yahoo.com> wrote:

> On Feb 21, 2023, at 04:55, Peter <pmc@citylink.dinoex.sub.org> wrote:
> 
>> On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote:
>> ! Peter <pmc_at_citylink.dinoex.sub.org> wrote on
>> ! Date: Tue, 21 Feb 2023 03:45:12 UTC :
>> ! 
>> ! > 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. 
>> ! > 
>> ! > 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).
>> ! > 
>> ! > 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)...
>> ! > 
>> ! > So, some inspiration would be welcome...
>> ! 
>> ! On thing to check on is if filemon.ko is loaded and operational.
>> ! META_MODE greatly depends on it.
>> 
>> That should be the case - 'kldstat' shows it (and I've seen warnings
>> where it didn't).
>> 
>> ! 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.
>> ! 
>> ! # cd /usr/src/
>> ! # env WITH_META_MODE=yes make buildworld
>> ! # env WITH_META_MODE=yes make installworld
>> ! # env WITH_META_MODE=yes make buildworld (again #0)
>> ! ## no more rebuilds below?
>> ! # env WITH_META_MODE=yes make buildworld (again #1)
>> ! # env WITH_META_MODE=yes make buildworld (again #2)
>> 
>> But what is the difference between #0 and #1?
> 
> 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.
> 
> 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.
> 
> make with -dM reports the likes of:
> 
>   file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target...
> 
> explicitly as it goes. As I remember tmp/legacy/usr/sbin/
> was always part of the path for what I found.
> 
> 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.
> 
> Note that the above make sequence was only intended
> for showing the dependency, not as instructions for a
> normal update sequence.
> 
>> . . .
>> 
>> ! See:
>> ! 
>> ! https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.html
> 
> 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.)
> 
> 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/awk/

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/awk/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.)

>> ! 
>> ! and:
>> ! 
>> ! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257616 .
>> 
>> Thank You, that's exactly the inspiration I was looking for!
>> Diving back in...
> 

===
Mark Millard
marklmi at yahoo.com