Re: port-arm/55704: multi-threaded applications for earmv[45]{,hf} freeze on COMPAT_NETBSD32 of aarch64

[Tobias Nygren <tnn%NetBSD.org@localhost>]

The following reply was made to PR port-arm/55704; it has been noted by GNATS.

From: Tobias Nygren <tnn%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-arm/55704: multi-threaded applications for earmv[45]{,hf}
 freeze on COMPAT_NETBSD32 of aarch64
Date: Thu, 8 Oct 2020 13:00:19 +0200

 > I'm not sure whether we can fix this problem without modifying userland
 > binaries for earmv[45]{,hf}. While arm variants prior to v6 realize
 > atomic_ops(3) by swp instruction (we emulate it for COMPAT_NETBSD32),
 > they does not have membar_ops(3), since they are not intended for
 > multi-processor machines. Actually, you can see our membar_ops(3) are
 > no-op for arm processors prior to v6:
 
 There were, in another context, discussions about need of pinning
 processes to the CPU they were launched on in some situations. There
 was some (don't recall the model) Samsung big.LITTLE SoC that only
 implements crypto instruction set extensions on the big cores.
 
 Can the compat layer detect at exec time if the binary is v[45] or v6+?
 for a purely userland solution you might be able to pin the process
 in ld.elf_so or with an LD_PRELOAD library.
 The problem with that is only root has permision to use pset(3).