Add the ability to pre-resolve architecture-specific EABI symbols and
use it on arm for selected EABI functions. These functions can be called
with rtld bind lock write-locked, so they should be resolved in forward.

Reported by:	Mark Millard <marklmi@yahoo.com>, John F Carr <jfc@mit.edu>
Reviewed by:	kib, imp
MFC after:	1 week
Differential Revision:  https://reviews.freebsd.org/D46104

(cherry picked from commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0)

(cherry picked from commit f8bbbce458194ff4312c610d32a64ff4a3a71d45)

Similarly as in the previous commit, using calloc() instead of malloc()
is useless here in the regular case since the subsequent call to
cpuset_getaffinify() is going to completely fill the allocated memory.

However, there is an additional complication.  This function tries to
allocate memory to hold the cpuset if it previously wasn't, and does so
before the thread lock is acquired, which can fail on a bad thread ID.
In this case, it is necessary to deallocate the memory allocated in this
function so that the attributes object appears unmodified to the caller
when an error is returned.  Without this, a subsequent call to
pthread_attr_getaffinity_np() would expose uninitialized memory (not
a security problem per se, since it comes from the same process) instead
of returning a full mask as it would before the failing call to
pthread_attr_get_np().  So the caller would be able to notice a change
in the state of the attributes object even if pthread_attr_get_np()
reported failure, which would be quite surprising.  A similar problem
that could occur on failure of cpuset_setaffinity() has been fixed.

Finally, we shall always report memory allocation failure.  This already
goes for pthread_attr_init(), so, if for nothing else, just be
consistent.

Reviewed by:            emaste, kib
Approved by:            emaste (mentor)
MFC after:              2 weeks
Sponsored by:           The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D43329

(cherry picked from commit aadb4a1b3fd185d547087f6eafca6ce0b4df3291)

Approved by:            markj (mentor)

Using calloc() instead of malloc() is useless here since the allocated
memory is to be wholly crushed by the memcpy() call that follows.

Suggested by:           kib
Reviewed by:            emaste, kib
Approved by:            emaste (mentor)
MFC after:              2 weeks
Differential Revision:  https://reviews.freebsd.org/D43328

(cherry picked from commit 15bb0300eeca233827a6a13cd2ed883e0034979d)

Approved by:            markj (mentor)

The change of argument for sizeof() (from a type to an object) is to be
consistent with the change done for the malloc() code just above in the
preceding commit touching this file.

Consider bit flags as integers and test whether they are set with an
explicit comparison with 0.

Use an explicit flag value (PTHREAD_SCOPE_SYSTEM) in place of a variable
that has this value at point of substitution.

All other changes are straightforward.

Suggested by:           kib
Reviewed by:            kib
Approved by:            emaste (mentor)
MFC after:              2 weeks
Differential Revision:  https://reviews.freebsd.org/D43327

(cherry picked from commit 4d312aa051414ad77d3515f258230d01ad11d6dc)

Approved by:            markj (mentor)

On first read, POSIX may seem ambiguous about the return code for some
scheduling-related pthread functions on invalid arguments.  But a more
thorough reading and a bit of standards archeology strongly suggests
that this case should be handled by EINVAL and that ENOTSUP is reserved
for implementations providing only part of the functionality required by
the POSIX option POSIX_PRIORITY_SCHEDULING (e.g., if an implementation
doesn't support SCHED_FIFO, it should return ENOTSUP on a call to, e.g.,
sched_setscheduler() with 'policy' SCHED_FIFO).

This reading is supported by the second sentence of the very definition
of ENOTSUP, as worded in CAE/XSI Issue 5 and POSIX Issue 6: "The
implementation does not support this feature of the Realtime Feature
Group.", and the fact that an additional ENOTSUP case was added to
pthread_setschedparam() in Issue 6, which introduces SCHED_SPORADIC,
saying that pthread_setschedparam() may return it when attempting to
dynamically switch to SCHED_SPORADIC on systems that doesn't support
that.

glibc, illumos and NetBSD also support that reading by always returning
EINVAL, and OpenBSD as well, since it always returns EINVAL but the
corresponding code has a comment suggesting returning ENOTSUP for
SCHED_FIFO and SCHED_RR, which it effectively doesn't support.

Additionally, always returning EINVAL fixes inconsistencies where EINVAL
would be returned on some out-of-range values and ENOTSUP on others.

Reviewed by:            markj
Approved by:            markj (mentor)
MFC after:              2 weeks
Sponsored by:           The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D43006

(cherry picked from commit 0eccb45979a8ee3129e11b638ebc4cfa00942b80)

Approved by:            markj (mentor)

Also, remove most comments, which don't add value.

Reviewed by:            emaste
Approved by:            markj (mentor)
MFC after:              2 weeks
Sponsored by:           The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D43005

(cherry picked from commit bd61c1e89dc4a40ba696de1785d423978e1c2147)

Approved by:            markj (mentor)

(cherry picked from commit 0dc52b72108e321a99022785713c58d278696af2)

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Similar commit in main:
(cherry picked from commit d0b2dbfa0ecf)

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Similar commit in main:
(cherry picked from commit 1d386b48a555)