9600 was a standard baud rate decades ago, but 115200 is now more common
so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains
unchanged.
Reviewed by: bz, imp, manu
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36295
Use at your own risk, but this will remove $FreeBSD$ from your tree. It
does commits and tries to be at least a little smart about it.
Sponsored by: Netflix
At the moment, several Makefiles under tests/ do not correctly generate
.depend files, which can lead to link errors when doing incremental
(e.g. WITHOUT_CLEAN) builds:
ld: error: undefined symbol: testing::internal::g_linked_ptr_mutex
>>> referenced by gtest-port.h:2137 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2137)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced by gtest-port.h:2139 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2139)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced by gtest-port.h:2139 (/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private/gtest/internal/gtest-port.h:2139)
>>> mockfs.o:(testing::internal::linked_ptr_internal::depart())
>>> referenced 3 more times
For the time being, put in a depend-cleanup.sh workaround for this.
Reported by: des
Reviewed by: emaste
Fixes: 28f6c2f292
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D41476
Toolchain components were historically statically linked. They became
normal dynamically linked executables in commit 6ab18ea64d. There is
no need to keep a special case build option for the toolchain; users who
want statically linked toolchain (or any other) components can use the
existing NO_SHARED knob.
Reviewed by: dim, sjg
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41266
Prior to Clang 13 (e.g. in the Clang 11 present in 13.0-RELEASE), the
resource directory logic for FreeBSD was broken and would not resolve
symlinks, meaning symlinks would only work if in a directory next to the
containing lib directory. Therefore we cannot even use a symlink for
worldtmp, we have to make a wrapper script that execs the real binary
via an absolute path.
Reported by: markj
Reviewed by: markj
Fixes: 65f28f63a7 ("tools/build: Create toolchain symlinks for non-absolute compiler/linker")
Differential Revision: https://reviews.freebsd.org/D41238
This option is a blanket for all the DTrace-related software. The option
when enabled passes in -fsanitize=address -fsanitize=undeifned, enabling
ASAN and UBSAN in the following components:
- libdtrace
- dtrace(1)
- lockstat(1)
- plockstat(1)
The option defaults to "no" and is intended as a developer aid.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D41157
If any of the toolchain variables are not absolute then we need to
create a symlink in WORLDTMP/legacy/bin in order to make them available
during a BUILD_WITH_STRICT_TMPPATH build.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D41188
By passing through _ALL_libcompats we can avoid hard-coding the list of
libcompats in depend-cleanup.sh. This cleanup also makes clean_dep
shorter by using a loop instead of handling each case explicitly (at the
expense of slightly tweaked logging).
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D41187
The removal of the sparc64 support in February 2020 obsoleted the
VTOC8 partitioning scheme as no other FreeBSD platform makes use
of it. Moreover, the code is bitrotting as nothing defines e. g.
LOADER_VTOC8_SUPPORT any more and, thus, should go now, too. With
this change, the following commits are reverted as far as VTOC8
is concerned and parts haven't already previously been deleted
along with prior sparc64 removals:
094fcb157da7d366e958ba8d50d08b
The alignment example d9711c28ef
added to the VTOC8 section of gpart.8 is folded into the MBR one.
This should finally conclude the deorbit of sparc64-specific bits.
We had joy, we had fun
we ran Unix on a Sun.
But that source and the song
of FreeBSD have all gone.
Credits to Michael Bueker for the original "Unix on a Sun" and Rod
McKuen for the "Seasons in the Sun" lyrics.
Perforce has been retired since 2019 (commit feea78990c), so there is
no need anymore to keep perforce tools. Plus, there is no need to
mention perforce admin.
Reviewed by: emaste, Olivier Certner
Differential Revision: https://reviews.freebsd.org/D41106
These are useful for testing new additions to the script. Whilst here,
harden the script a little and improve error messages.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31007
We run depend-cleanup.sh twice during the build. The second time is the
normal run, where we run it under WMAKEENV and thus have CROSSENV's
MACHINE(_ARCH)=${TARGET(_ARCH)} in the environment. However, the first
time is for bootstrap-tools, where it's run under BMAKEENV and we don't
have any assignments to MACHINE(_ARCH) in the environment, meaning the
script sees them as unset. In practice this doesn't matter since the
only use doesn't apply to bootstrap-tools, but it could be a future
issue. Thus, explicitly export them for depend-cleanup.sh and have the
script verify they're set.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40968
Now that depend-cleanup.sh handles 32-bit dependencies a bit better, get
rid of the stale ffs.S ones, otherwise an incremental build on amd64
will fail with:
cc: error: no such file or directory: '/usr/src/lib/libc/i386/string/ffs.S'
Fixes: ee8b0c436d
For example with the recent removal of ffs.S for 32-bit arm and i386,
the egrep in clean_dep() did not find any files to remove, even if you
added a "clean_dep lib/libc ffs S" line. This is because it will never
find the ffs.S filename in the 64-bit .depend files for libc.
Split the searching and removing of 32-bit dependencies and objects into
a separate part to cope with this. This can be used similarly later on,
for other bitnesses.
MFC after: 3 days
This can be run inside a bhyve guest to query the value of fwctl
nodes. Note that fwctl in bhyve only supports a single hw.ncpu node.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40803
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
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
If we find an object corresponding to a source file that existed in
OpenSSL 1.1.1 but not in 3.0 just remove all of the OpenSSL objdirs.
Reviewed by: dhw
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40750
The makeman CI job ensures that all options have description files.
Bring the CI job back to green by adding back WITHOUT_CAPSICUM and
WITHOUT_CASPER description files (that now state the assoicated options
have no effect).
Fixes: c24c117b96 ("Remove WITHOUT_{CAPSICUM,CASPER} options")
Sponsored by: The FreeBSD Foundation
At this point CAPSICUM and CASPER are merely forced on via the newly
added __REQUIRED_OPTIONS list; after stable/14 branches I'll sweep
the tree for MK_{CAPSICUM,CASPER}.
This change will not be MFCed.
Discussed on: freebsd-arch
Differential Revision: https://reviews.freebsd.org/D40592
