Re: 13.2 BETA2: how do debug META_MODE?

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.

> ! 
> ! 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