Date: Wed, 2 Jan 2019 17:21:03 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-hackers Hackers <freebsd-hackers@freebsd.org> Subject: 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 Message-ID: <BFD0D25C-42D6-47EF-8F31-1B313904305D@yahoo.com>
next in thread | raw e-mail | index | archive | help
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 =3D 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 =3D 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=3D12, =
rfds=3D0x7ffffffe3650, wfds=3D0x0, efds=3D0x0, timo=3D0x0, =
mask=3D0x7ffffffe3600) at /usr/src/lib/libthr/thread/thr_syscalls.c:378
#2 0x000000006004928d in do_freebsd_select (env=3D0x860edfb18, =
n=3D<optimized out>, rfd_addr=3D140736934698744, wfd_addr=3D<optimized =
out>, efd_addr=3D0, target_tv_addr=3D0)
at =
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b=
sd-user/freebsd/os-time.h:468
#3 do_freebsd_syscall (cpu_env=3D0x860edfb18, num=3D93, arg1=3D12, =
arg2=3D140736934698744, arg3=3D0, arg4=3D0, arg5=3D0, arg6=3D274914043516,=
arg7=3D274913946564, arg8=3D6579811)
at =
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b=
sd-user/syscall.c:1106
#4 0x000000006003903c in target_cpu_loop (env=3D0x860edfb18) at =
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b=
sd-user/aarch64/target_arch_cpu.h:100
#5 0x0000000060038e09 in cpu_loop (env=3D0xc) at =
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b=
sd-user/main.c:121
#6 0x0000000060039ecb in main (argc=3D<optimized out>, =
argv=3D0x7fffffffd360) at =
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/b=
sd-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:=20
=
https://www.freebsd.org/cgi/man.cgi?query=3Dsigprocmask&apropos=3D0&sektio=
n=3D2&manpath=3DFreeBSD+13-current&arch=3Ddefault&format=3Dhtml
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=20
* 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=3D"" ; if [=20
root 89283 0.0 0.0 11160 2108 0 IJ 13:30 0:00.10 | =
| `-- /bin/sh ./configure --enable-nls =
--prefix=3D/usr/local --localstatedir=3D/var --mandir=3D/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.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFD0D25C-42D6-47EF-8F31-1B313904305D>