Code questions tied to a qemu-aarch64-static hang-up that I observe during a amd64->aarch64 poudriere-devel based bulk cross-build of some ports

[Mark Millard]

The following code is from where I see a hang-up in qemu-aarch64-static:

/* select(2) */
static inline abi_long do_freebsd_select(CPUArchState *env, int n,
        abi_ulong rfd_addr, abi_ulong wfd_addr, abi_ulong efd_addr,
        abi_ulong target_tv_addr)
{
. . . (omitted material . . .
    sigfillset(&mask);
    sigprocmask(SIG_BLOCK, &mask, &omask);
    if (ts->signal_pending) {
        . . . (omitted) . . .
    } else {
        ret = get_errno(pselect(n, rfds_ptr, wfds_ptr, efds_ptr, ts_ptr,
                    &omask));
        sigprocmask(SIG_SETMASK, &omask, NULL);
    }

So more directly for the path taken:, with some comments added that are
tied to my question:

    // signals might not be blocked here
    sigfillset(&mask);
    sigprocmask(SIG_BLOCK, &mask, &omask);
    // so signals are blocked
    // but the below reneables them during waitin in pselect
    // (if they were not blocked before the sigprocmask call).
    ret = get_errno(pselect(n, rfds_ptr, wfds_ptr, efds_ptr, ts_ptr,
                    &omask));
    // signals are again blocked during parts of pselect
    // and here after returning.
    sigprocmask(SIG_SETMASK, &omask, NULL);
    // signals are no longer blocked

Question
Is there a reason for this code structure to be used? If so, what is it?

I've another qeuestion based on what gdb reports and man pages
say. (I extracted material from records of multiple gdb sessions.)

(gdb) bt
#0  _pselect () at _pselect.S:3
#1  0x00000000601da57f in __thr_pselect (count=12, rfds=0x7ffffffe3650, wfds=0x0, efds=0x0, timo=0x0, mask=0x7ffffffe3600) at /usr/src/lib/libthr/thread/thr_syscalls.c:378
#2  0x000000006004928d in do_freebsd_select (env=0x860edfb18, n=<optimized out>, rfd_addr=140736934698744, wfd_addr=<optimized out>, efd_addr=0, target_tv_addr=0)
   at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-time.h:468
#3  do_freebsd_syscall (cpu_env=0x860edfb18, num=93, arg1=12, arg2=140736934698744, arg3=0, arg4=0, arg5=0, arg6=274914043516, arg7=274913946564, arg8=6579811)
   at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1106
#4  0x000000006003903c in target_cpu_loop (env=0x860edfb18) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/aarch64/target_arch_cpu.h:100
#5  0x0000000060038e09 in cpu_loop (env=0xc) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/main.c:121
#6  0x0000000060039ecb in main (argc=<optimized out>, argv=0x7fffffffd360) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/main.c:513

Note the use of __thr_pselect . But I see in gdb's disass:

   0x00000000600490ab <+33227>:	callq  0x602b3b20 <sigprocmask>
   0x00000000600490b0 <+33232>:	cmpl   $0x0,0x19440(%r12)
   0x00000000600490b9 <+33241>:	je     0x60049262 <do_freebsd_syscall+33666>
. . .
   0x0000000060049262 <+33666>:	mov    -0x2f8(%rbp),%rsi
   0x0000000060049269 <+33673>:	mov    -0x2f0(%rbp),%rdx
   0x0000000060049270 <+33680>:	mov    -0x2e8(%rbp),%rcx
   0x0000000060049277 <+33687>:	lea    -0x2e0(%rbp),%r9
   0x000000006004927e <+33694>:	mov    -0x2b8(%rbp),%rdi
   0x0000000060049285 <+33701>:	mov    %r14,%r8
   0x0000000060049288 <+33704>:	callq  0x601e1cb0 <pselect>

Yet: 

https://www.freebsd.org/cgi/man.cgi?query=sigprocmask&apropos=0&sektion=2&manpath=FreeBSD+13-current&arch=default&format=html

reports the following:

QUOTE
In threaded applications, pthread_sigmask(3) must be used instead of sigprocmask().
END QUOTE

But gdb shows use of 2 threads overall:

(gdb) info threads
 Id   Target Id                   Frame 
* 1    LWP 100804 of process 89695 _pselect () at _pselect.S:3
 2    LWP 101548 of process 89695 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37

So is the apparent use of sigprocmask valid in this context?


For reference for where the hang-up happens for:

configure:6844: checking whether // is distinct from /

The result is:

root       87913    0.0  0.0  12920  3668  0  I    13:29       0:00.06 | |           `-- sh: poudriere[FBSDFSSDjailCortexA57-default][01]: build_pkg (texinfo-6.5_1,1) (sh)
root       88869    0.0  0.0  12920  3660  0  I    13:29       0:00.00 | |             `-- sh: poudriere[FBSDFSSDjailCortexA57-default][01]: build_pkg (texinfo-6.5_1,1) (sh)
root       88870    0.0  0.0  10412  1848  0  IJ   13:29       0:00.01 | |               `-- /usr/bin/make -C /usr/ports/print/texinfo configure
root       88974    0.0  0.0  10272  1812  0  IJ   13:30       0:00.00 | |                 `-- /bin/sh -e -c (cd /wrkdirs/usr/ports/print/texinfo/work/texinfo-6.5 &&  _LATE_CONFIGURE_ARGS="" ;  if [ 
root       89283    0.0  0.0  11160  2108  0  IJ   13:30       0:00.10 | |                   `-- /bin/sh ./configure --enable-nls --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --di
root       89692    0.0  0.0 227368 14504  0  IJ   13:30       0:00.03 | |                     `-- /usr/local/bin/qemu-aarch64-static wc //dev/null
root       89694    0.0  0.0 227424 14596  0  IJ   13:30       0:00.01 | |                       `-- /usr/local/bin/qemu-aarch64-static wc //dev/null
root       89695    0.0  0.0 227584 14720  0  IJ   13:30       0:00.01 | |                         `-- wc: zygote (qemu-aarch64-static)


wc (via qemu-aarch64-static) gets stuck in what apparently was a select request
that turned into a pselect use. (do_freebsd_pselect was not called.)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)