make copies instead.
There's too many times that we can't run the new binaries with old
libraries. Making the links when things are known to be 'safe' is a
nice optimization, but a copy of all the binaries is only 30MB, so
saving the copies at the cost of increased support when new symbols
are added and used as part of the bootstrap seems to be unwise.
There may be additional optimizations possible here, especially for
!FreeBSD hosts. However, that's beyond the scope of the problem I'm
trying to fix with make failing mid-way through an installworld across
change r363679. This optimization there caused us to run a new binary
with an old library once a new make was installed due to the symbolic
link. One could just copy make, but then other binaries fail as well,
so rather than play whack-a-mole, I opted to take us back to the old
way. Before r340157 or so we did copies (thogh of a lot fewer
artifacts), and we didn't have issues like this.
Reviewed by: arichards@
Differential Revision: https://reviews.freebsd.org/D25967
extensible arrays implementation.
While at it add some more comments explaining the current
radix_tree_insert() function and make sure to clean the root node when
the radix tree reaches the maximum height. This can happen if the
index passed is too big when the tree is empty.
The radix_tree_store() function is basically a copy of the
radix_tree_insert() function with some added functionality.
The radix_tree_store() function is local to FreeBSD and does not yet
exist in Linux.
Reviewed by: kib
MFC after: 1 week
Sponsored by: Mellanox Technologies
Not marking the function as static can result in a linker error:
undefined reference to __assfail [--no-allow-shlib-undefined]
I noticed this error after updating our CHERI LLVM to the latest upstream
LLVM HEAD revision.
This change effectively reverts r329984 and marks dmu_buf_init_user as
static (which keeps the GCC build happy).
Reviewed By: #zfs, asomers, freqlabs, mav
Differential Revision: https://reviews.freebsd.org/D25663
This breaks the build on macOS where this header doesn't exist. I could
also add a compat header to tools/build/cross-build but since it's not
needed removing it seems like the better solution.
Make sure to reclaim epoch structures when they are freed to support
dynamic allocation and freeing of epoch structures.
While at it, move the 64 supported epoch control structures to the
static memory domain. This overall simplifies the management and
debugging of system epoch's.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D25960
MFC after: 1 week
Sponsored by: Mellanox Technologies
When using v4-mapped IPv6 sockets with IPV6_PKTINFO we do not
respect the given v4-mapped src address on the IPv4 socket.
Implement the needed functionality. This allows single-socket
UDP applications (such as OpenVPN) to work better on FreeBSD.
Requested by: Gert Doering (gert greenie.net), pfsense
Tested by: Gert Doering (gert greenie.net)
Reviewed by: melifaro
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24135
Add IEEE80211_IOC_IC_NAME to query the ic_name field and in ifconfig
to print the parent interface again. This functionality was lost
around r287197. It helps in case of multiple wlan interfaces and
multiple underlying hardware devices to keep track which wlan
interface belongs to which physical device.
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Reviewed by: adrian, Idwer Vollering
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25832
Netmap only uses free list 0 to keep it consistent with its
one-to-one mapping between each netmap ring and a device RX
(or TX) queue.
However, the current iflib_netmap_rxsync() routine was
mistakenly updating the ifl_cidx field of both free lists.
PR: 248494
MFC after: 2 weeks
The FreeBSD em driver fails to properly reset the VME flag
in the e1000 CTRL register oneg the following ifconfig command
ifconfig em1 -vlanhwtag
Tested on the e1000 device emulated by QEMU, and on a real
NIC (chip=0x10d38086).
PR: 236584
Submitted by: murat@sunnyvalley.io
Reported by: murat@sunnyvalley.io
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D25286
required by both the static analyzer (MK_CLANG_FULL) and clang-format
(MK_CLANG_FORMAT). We could also invent yet another SRCS variant, but
that seems a bit overkill.
We need to provide a struct passwd that is compatible with the target
system and this is not the case when cross-building from macOS/Linux.
It should also be a problem when bootstrapping for an i386 target from a
FreeBSD amd64 host since time_t does not match across those systems.
However, pwd_mkdb always truncates integer values to 32-bit so this
difference does not result in different databases.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D25931
This does not appear to matter on FreeBSD or Linux, but when building an
amd64 kernel on macOS I was seeing infinite loops in ctfmerge.
It turns out the loop in wip_save_work() was looping forever due to
pthread_cond_wait() always returning -EINVAL.
Reviewed By: markj, brooks
Differential Revision: https://reviews.freebsd.org/D25973
usr.sbin/yp_mkdb/yp_mkdb.c:91:40: error: format specifies type 'char *' but the argument has type 'void *' [-Werror,-Wformat]
printf("%.*s %.*s\n", (int)key.size, key.data, (int)data.size,
~~~~ ^~~~~~~~
usr.sbin/yp_mkdb/yp_mkdb.c:92:7: error: format specifies type 'char *' but the argument has type 'void *' [-Werror,-Wformat]
data.data);
^~~~~~~~~
MFC after: 3 days
lib/libpam/modules/pam_exec/pam_exec.c:222:56: error: format specifies type 'char *' but the argument has type 'const void *' [-Werror,-Wformat]
if (asprintf(&envstr, "%s=%s", pam_item_env[i].name, item) < 0)
~~ ^~~~
llvm: Default to -mno-relax on RISC-V
Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN
requires unimplemented linker relaxation; recompile with -mno-relax'.
Our default linker (ld.lld) doesn't support relaxation, so default to
no-relax so we don't generate object files the linker can't handle.
Reviewed by: mhorne
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25210
It allows to report to initiator LU identifying information, preset via
"ident_info" and "text_ident_info" options.
Unfortunately it is impossible to implement SET IDENTIFYING INFORMATION,
since we have no persistent storage it requires, so the information is
read-only for initiator and has to be set out-of-band.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
lldb: use lua as the default script language
In the FreeBSD base system we do not have Python support in lldb, but
will have Lua support. Make Lua the default.
This needs to be made into a configure-time option; that is being
discussed upstream and will appear in a future lldb import. For now
carry this change as a tiny patch to our copy of lldb.
[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time
Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.
On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.
This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim
Differential Revision: https://reviews.freebsd.org/D22549
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM.
In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)
PR: 233664
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called. Export the same ones from LLVM-libunwind's
libgcc_s, on ARM. As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files. This allows
the ARM-specific Symbol.map to be included only on ARM.
Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.
No functional change intended for non-ARM architectures.
This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).
On ELFv2, the overflow parameters in the stack frame are at a different offset
from sp than ELFv1. Adjust code to use the correct offset in all cases.
This had resulted in argv[8] and up being copied to the incorrect address
in the new context's initial stack frame.
This is not necessarily the only bug in this function, I need to do a full
review still and ensure the rest of the math is sane for ELFv2 stack frames.
Reported by: pherde (Probably. My notes are a bit unclear.)
Reviewed by: jhibbits (in irc)
Sponsored by: Tag1 Consulting, Inc.
lldb: shorten thread names to make logs easier to follow
lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated. This made logs hard
to read, as the truncated thread name ran into the log message. Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.
(Upstreaming to lldb still to be done).
Apply a workaround to be able to build clang 8.0.0 headers with clang
3.4.1, which is still in the stable/10 branch.
It looks like clang 3.4.1 implements static_asserts by instantiating a
temporary static object, and if those are in an anonymous union, it
results in "error: anonymous union can only contain non-static data
members".
To work around this implementation limitation, move the static_asserts
in question out of the anonymous unions.
This should make building the latest stable/11 from stable/10 possible
again.
Reported by: Mike Tancsa <mike@sentex.net>
Put in a temporary workaround for what is likely a gcc 6 bug (it does
not occur with gcc 7 or later). This should prevent the following error
from breaking the head-amd64-gcc CI builds:
In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0:
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
using std::vector<lldb_private::MemoryRegionInfo>::vector;
^~~~~~
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
Reported by: CI
