qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes

[Mark Millard]

[Context: head (12) -r312009 and ports head -r431413.]

I've been experimenting on amd64 with poudriere-devel with -x
for -a arm.armv6 and I ran into:

> TCG temporary leak before 00021826
> qemu: uncaught target signal 4 (Illegal instruction) - core dumped

in 3 of the 31 ports for the build, but 4 skipped so 3 of 27
attempted. The 00021826 is the same number in all the examples
so far (whatever its base).

These seem to be the only TCG messages and each failure starts with
one and then reports the qemu message. (Also true for the below.)
As far as I can tell the TCG notice is the report of an internal
qemu problem that is then translated into an Illegal instruction.

This was with ALLOW_MAKE_JOBS=yes but -J 1 for poudriere.

For 2 of the problem ports retries worked, still using
ALLOW_MAKE_JOBS=yes and -J 1 .

But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=yes
--but in a different step each time.

In all failure cases it was gmake that got the "illegal instruction".

But disabling ALLOW_MAKE_JOBS=yes appears (so far) to avoid the
issue. For example, that 3rd failing port built fine. (I've
been doing more ports since, with ALLOW_MAKE_JOBS=yes repeatedly
failing and lack of it working.)

My guess is SIGCHLD delivery sometimes touches something (or a timing)
that is not handled well in qemu-arm-static. I've had not problems
on an rpi2 or bpim3 in the past.

(I have seen some analogous "soemtimes" issues on powerpc under
and version of lang that mishandled the stack part of the ABI
FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time
for the messed up code generation, leading to stack corruption. Code
not getting signals had no problems.)

Note: The amd64 context is FreeBSD under VirtualBox under macOS
and it has had no problem for native builds of world, kernel,
or ports.

===
Mark Millard
markmi at dsl-only.net