[kvm-unit-tests] riscv build failure

[Joel Stanley]

On Fri, 5 Sept 2025 at 07:54, Andrew Jones <andrew.jones at linux.dev> wrote:

> I applied similar steps but couldn't reproduce this. It also looks like we
> have a dependency because configuring with '--cc=/path/to/mygcc', where
> mygcc is
>
>    #!/bin/bash
>    for x in $@; do
>        if [[ $x =~ sbi-asm ]] && ! [[ $x =~ sbi-asm-offsets ]]; then
>            sleep 5
>            break
>        fi
>    done
>    /path/to/riscv64-linux-gnu-gcc $@
>
> stalls the build 5 seconds when compiling sbi-asm.S but doesn't reproduce
> the issue. That said, running make with -d shows that riscv/sbi-asm.o is
> an implicit prerequisite, although so are other files. I'm using
> GNU Make 4.4.1. Which version are you using?

As Nick discovered, it was the older version of make that was causing
the issue. Thanks to you both for sorting it out! I'll send the patch
along to buildroot.

> Also, while the steps above shouldn't cause problems, they are a bit odd
>  * '--endian' only applies to ppc64
>  * -j385 is quite large and specific. Typicall -j$(nproc) is recommended.

This is a curious number. I went digging, it seems buildroot does a $nproc+1:

PARALLEL_JOBS := $(shell echo \
        $$((1 + `getconf _NPROCESSORS_ONLN 2>/dev/null || echo 1`)))

Knowing how these things go I'm sure there is some reason they do this
instead of calling nproc.

Less counting perhaps? getconf ends up reading sysfs:

openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
read(3, "0-383\n", 1024)                = 6

Whereas nproc calls sched_getaffinity, and then depending on how new
the glibc is will loop over all the CPUs to get a count:

sched_getaffinity(0, 128, [0 ... 383]) = 48

coreutils has this to say:

  /* On systems with a modern affinity mask system call, we have
         sysconf (_SC_NPROCESSORS_CONF)
            >= sysconf (_SC_NPROCESSORS_ONLN)
               >= num_processors_via_affinity_mask ()
     The first number is the number of CPUs configured in the system.
     The second number is the number of CPUs available to the scheduler.
     The third number is the number of CPUs available to the current process.

     Note! On Linux systems with glibc, the first and second number come from
     the /sys and /proc file systems (see
     glibc/sysdeps/unix/sysv/linux/getsysstats.c).
     In some situations these file systems are not mounted, and the sysconf call
     returns 1 or 2 (<https://sourceware.org/bugzilla/show_bug.cgi?id=21542>),
     which does not reflect the reality.  */

Anyway. That's how we arrived at 385!

Cheers,

Joel