Retire MK_PROFILE infrastructure

It was disabled by default in fe52b7f60ef4. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.

Relnotes: Yes
Reviewed

Retire MK_PROFILE infrastructure

It was disabled by default in fe52b7f60ef4. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.

Relnotes: Yes
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31558

show more ...

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

rtld: actually resolve memcpy plt

The call to memcpy() meant to cause plt resolution in _thr_rtld_init()
was getting optimized by the compiler. Tell the compiler not to use its
builtins in thr_rtld

rtld: actually resolve memcpy plt

The call to memcpy() meant to cause plt resolution in _thr_rtld_init()
was getting optimized by the compiler. Tell the compiler not to use its
builtins in thr_rtld.c. We could avoid just the memcpy builtin but
disabling all will be more robust against future changes.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D45891

show more ...

Add a build knob for _FORTIFY_SOURCE

In the future, we will Default to _FORTIFY_SOURCE=2 if SSP is enabled,
otherwise default to _FORTIFY_SOURCE=0. For now we default it to 0
unconditionally to eas

Add a build knob for _FORTIFY_SOURCE

In the future, we will Default to _FORTIFY_SOURCE=2 if SSP is enabled,
otherwise default to _FORTIFY_SOURCE=0. For now we default it to 0
unconditionally to ease bisect across older versions without the new
symbols, and we'll put out a call for testing.

include/*.h include their ssp/*.h equivalents as needed based on the
knob. Programs and users are allowed to override FORTIFY_SOURCE in their
Makefiles or src.conf/make.conf to force it off.

Reviewed by: des, markj
Relnotes: yes
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D32308

show more ...

libthr: remove explicit sys/cdefs.h includes

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

lib{c,thr}: add DT_RUNPATH for gcc -m32

To allow gcc -m32 to work, link libc and libthr with --rpath-/usr/lib32.
When called with -m32, gcc is currently unable to communicate to
the bfd linker that

lib{c,thr}: add DT_RUNPATH for gcc -m32

To allow gcc -m32 to work, link libc and libthr with --rpath-/usr/lib32.
When called with -m32, gcc is currently unable to communicate to
the bfd linker that it should look in /usr/lib32 to resolve needed (as
opposed to explicitly linked) libraries so we need to provide a hint.

See also: https://sourceware.org/bugzilla/show_bug.cgi?id=31395

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43910

show more ...

lib{c,sys}: move auxargs more firmly into libsys

Continue to filter the public interface (elf_aux_info()), but entierly
relocate the private interfaces (_elf_aux_info(),
__init_elf_aux_vector(), and

lib{c,sys}: move auxargs more firmly into libsys

Continue to filter the public interface (elf_aux_info()), but entierly
relocate the private interfaces (_elf_aux_info(),
__init_elf_aux_vector(), and __elf_aux_vector) to libsys.

This ensures that rtld updates the correct (only) copy of
__elf_aux_vector. After 968a18975adc9c2a619bb52aa2f009de99fc9e24
updates were confused and __getosreldate was failing, causing
the system to fall back to compat compat12 syscalls in some cases.

Return to explicitly linking libc to libsys and link libthr with libc
and libsys (in that order).

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43910

show more ...

libthr: filter rather than link with libsys

The allows gcc + GNU ld to link programs with -m32 -pthread without
erroring out due to _umtx_op_err being undefined (unless -lsys is added
to the link co

libthr: filter rather than link with libsys

The allows gcc + GNU ld to link programs with -m32 -pthread without
erroring out due to _umtx_op_err being undefined (unless -lsys is added
to the link command.

We now always link _umtx_op_err into libthr (not just when it's static)
and filter it with libsys so we call that implementation. The dynamic
implementations (at least the assembly ones) should likely become stubs
as a further refinement.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43783

show more ...

libthr: move _umtx_op_err() to libsys

Declare in sys/umtx.h and implement in libsys. Explicitly link libthr
with libsys.

When building libthr static include _umtx_op_err so we don't break static
l

libthr: move _umtx_op_err() to libsys

Declare in sys/umtx.h and implement in libsys. Explicitly link libthr
with libsys.

When building libthr static include _umtx_op_err so we don't break static
linkage with -lpthread.

Reviewed by: kib, emaste, imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/908

show more ...

Remove $FreeBSD$: one-line sh pattern

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

libthr: Add src.conf variable WITHOUT_PTHREADS_ASSERTIONS

This patch fixes a bug which prevents building libthr without
_PTHREADS_INVARIANTS defined. The default remains to build libthr
with -D_PTHR

libthr: Add src.conf variable WITHOUT_PTHREADS_ASSERTIONS

This patch fixes a bug which prevents building libthr without
_PTHREADS_INVARIANTS defined. The default remains to build libthr
with -D_PTHREADS_INVARIANTS. However, with this patch, if one builds
libthr with WITHOUT_PTHREADS_ASSERTIONS=true then the latency to
acquire+release a default pthread mutex is reduced by roughly 5%, and a
robust mutex by roughly 18% (as measured by a simple synthetic test on a
Xeon E5-2697a based machine).

Reviewed by: jhb, kib, mjg
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40900

show more ...

libthr: Disable stack unwinding on ARM.

When a thread exits, _Unwind_ForcedUnwind() is used to walk up stack
frames executing pending cleanups pushed by pthread_cleanup_push().
The cleanups are popp

libthr: Disable stack unwinding on ARM.

When a thread exits, _Unwind_ForcedUnwind() is used to walk up stack
frames executing pending cleanups pushed by pthread_cleanup_push().
The cleanups are popped by thread_unwind_stop() which is passed as a
callback function to _Unwind_ForcedUnwind().

LLVM's libunwind uses a different function type for the callback on
32-bit ARM relative to all other platforms. The previous unwind.h
header (as well as the unwind.h from libcxxrt) use the non-ARM type on
all platforms, so this has likely been broken on 32-bit arm since it
switched to using LLVM's libunwind.

For now, just disable stack unwinding on 32-bit arm to unbreak the
build until a proper fix is tested.

show more ...

Install unwind.h into /usr/include

Install headers from LLVM's libunwind in place of the headers from
libcxxrt and allow C applications to use the library.

As part of this, remove include/unwind.h

Install unwind.h into /usr/include

Install headers from LLVM's libunwind in place of the headers from
libcxxrt and allow C applications to use the library.

As part of this, remove include/unwind.h and switch libthr over to
using the installed unwind.h.

Reviewed by: dim, emaste
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D34065

show more ...

libthr: work around an ASAN false-positive

I got the following error with an ASAN-instrument libthr:

==803==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdb0 at pc 0x00080186

libthr: work around an ASAN false-positive

I got the following error with an ASAN-instrument libthr:

==803==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdb0 at pc 0x000801863396 bp 0x7ff8
READ of size 4 at 0x7fffffffcdb0 thread T0
#0 0x801863395 in handle_signal /local/scratch/alr48/cheri/freebsd/lib/libthr/thread/thr_sig.c:262:2
#1 0x801860da2 in thr_sighandler /local/scratch/alr48/cheri/freebsd/lib/libthr/thread/thr_sig.c:246:2

Address 0x7fffffffcdb0 is located in stack of thread T0 at offset 208 in frame
#0 0x80186080f in thr_sighandler /local/scratch/alr48/cheri/freebsd/lib/libthr/thread/thr_sig.c:213

This frame has 1 object(s):
[32, 64) 'act' (line 216) <== Memory access at offset 208 overflows this variable
HINT: this may be a false positive if your program uses some custom stack

This seems like a false-positive since the line in question is
`SIGSETOR(actp->sa_mask, ucp->uc_sigmask);` and it complains about a read
operation (from the ucontext_t argument) so this indicates to me that ASAN
does not understand that thr_sighandler() is a signal handler.

Differential Revision: https://reviews.freebsd.org/D31074

show more ...

Don't add -Winline for WARNS=6

This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standar

Don't add -Winline for WARNS=6

This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standard library with GCC.

This flag was originally added in back in r94332 but the flag is a no-op
in Clang ("This diagnostic flag exists for GCC compatibility, and has no
effect in Clang"). Removing it should make the GCC build output slightly
more readable.

Reviewed By: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D29235

show more ...

Remove tests for obsolete compilers in the build system

Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
f

Remove tests for obsolete compilers in the build system

Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.

Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802

show more ...

MFHead@r345880

Fix initial exec TLS mode for dynamically loaded shared objects.

If dso uses initial exec TLS mode, rtld tries to allocate TLS in
static space. If there is no space left, the dlopen(3) fails. If spa

Fix initial exec TLS mode for dynamically loaded shared objects.

If dso uses initial exec TLS mode, rtld tries to allocate TLS in
static space. If there is no space left, the dlopen(3) fails. If space
if allocated, initial content from PT_TLS segment is distributed to
all threads' pcbs, which was missed and caused un-initialized TLS
segment for such dso after dlopen(3).

The mode is auto-detected either due to the relocation used, or if the
DF_STATIC_TLS dynamic flag is set. In the later case, the TLS segment
is tried to allocate earlier, which increases chance of the dlopen(3)
to succeed. LLD was recently fixed to properly emit the flag, ld.bdf
did it always.

Initial test by: dumbbell
Tested by: emaste (amd64), ian (arm)
Tested by: Gerald Aryeetey <aryeeteygerald_rogers.com> (arm64)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19072

show more ...

MFHead@r345677

revert r341429 "disable BIND_NOW in libc, libthr, and rtld"

r345620 by kib@ fixed the rtld issue that caused a crash at startup
during resolution of libc's ifuncs with BIND_NOW.

PR: 233333
Sponsor

revert r341429 "disable BIND_NOW in libc, libthr, and rtld"

r345620 by kib@ fixed the rtld issue that caused a crash at startup
during resolution of libc's ifuncs with BIND_NOW.

PR: 233333
Sponsored by: The FreeBSD Foundation

show more ...

Merge ^/head r343571 through r343711.

Rename rtld-elf/malloc.c to rtld-elf/rtld_malloc.c.

Then malloc.c file name is too generic to use it for libthr.a.

Sponsored by: The FreeBSD Foundation
MFC after: 13 days

Merge ^/head r343320 through r343570.

Untangle jemalloc and mutexes initialization.

The need to use libc malloc(3) from some places in libthr always
caused issues. For instance, per-thread key allocation was switched to
use plain mmap(

Untangle jemalloc and mutexes initialization.

The need to use libc malloc(3) from some places in libthr always
caused issues. For instance, per-thread key allocation was switched to
use plain mmap(2) to get storage, because some third party mallocs
used keys for implementation of calloc(3).

Even more important, libthr calls calloc(3) during initialization of
pthread mutexes, and jemalloc uses pthread mutexes. Jemalloc provides
some way to both postpone the initialization, and to make
initialization to use specialized allocator, but this is very fragile
and often breaks. See the referenced PR for another example.

Add the small malloc implementation used by rtld, to libthr. Use it in
thr_spec.c and for mutexes initialization. This avoids the issues with
mutual dependencies between malloc and libthr in principle. The
drawback is that some more allocations are not interceptable for
alternate malloc implementations. There should be not too much memory
use from this allocator, and the alternative, direct use of mmap(2) is
obviously worse.

PR: 235211
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D18988

show more ...

Merge ^/head r340918 through r341763.