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
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).
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
Create new EINTEGRITY error with message "Integrity check failed".
An integrity check such as a check-hash or a cross-correlation failed.
The integrity error falls between EINVAL that identifies errors in
parameters to a system call and EIO that identifies errors with the
underlying storage media. EINTEGRITY is typically raised by intermediate
kernel layers such as a filesystem or an in-kernel GEOM subsystem when
they detect inconsistencies. Uses include allowing the mount(8) command
to return a different exit value to automate the running of fsck(8)
during a system boot.
These changes make no use of the new error, they just add it. Later
commits will be made for the use of the new error number and it will
be added to additional manual pages as appropriate.
Reviewed by: gnn, dim, brueffer, imp
Discussed with: kib, cem, emaste, ed, jilles
Differential Revision: https://reviews.freebsd.org/D18765
lldb: remove assertion that target_arch is FreeBSD
The target is not necessarily a FreeBSD binary - for example, it may be
a Linux binary running under the linuxulator. Basic ptrace (live)
debugging already worked in this case, except for the assertion.
Sponsored by: Turing Robotic Industries Inc.
Do not include float interfaces when using libsa.
We don't support float in the boot loaders, so don't include
interfaces for float or double in systems headers. In addition, take
the unusual step of spiking double and float to prevent any more
accidental seepage.
For our lldb customizations, instead of commenting out lines, use #ifdef
LLDB_ENABLE_ALL / #endif preprocess directives instead, so our diffs
against upstream only consist of added lines.
(Note that upstream has largely reshuffled the way optional lldb plugins
are handled, so we need a lot less of these #ifdefs. However, not all of
them can be dropped, unless we re-import several sources that we have
always skipped.)
This revision worked around an endless recursion when compiling clzdi2.c
and ctzdi2.c with gcc, upstream landed a different workaround for this
in https://reviews.llvm.org/rL324593, which is effective enough.
Noticed by: jrtc27
Merge lld trunk r321017 to contrib/llvm/tools/lld.
(Note that in this merge, I foolishly combined upstream changes with
this local change. But only this ifdef part is really needed, as we
always default to ELF link mode.)
Since this is contrib code, create an upstreamable version of my
change. Now on FreeBSD and NetBSD if _STANDALONE is defined, we
include the kernel version with alloances for the quirky differences
between the two.
Sponsored by: Netflix
o Replace __riscv__ with __riscv
o Replace __riscv64 with (__riscv && __riscv_xlen == 64)
This is required to support new GCC 7.1 compiler.
This is compatible with current GCC 6.1 compiler.
RISC-V is extensible ISA and the idea here is to have built-in define
per each extension, so together with __riscv we will have some subset
of these as well (depending on -march string passed to compiler):
__riscv_compressed
__riscv_atomic
__riscv_mul
__riscv_div
__riscv_muldiv
__riscv_fdiv
__riscv_fsqrt
__riscv_float_abi_soft
__riscv_float_abi_single
__riscv_float_abi_double
__riscv_cmodel_medlow
__riscv_cmodel_medany
__riscv_cmodel_pic
__riscv_xlen
Reviewed by: ngie
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11901
libunwind: make __{de,}register_frame compatible with libgcc API
The libgcc __register_frame and __deregister_frame functions take a
pointer to a set of FDE/CIEs, terminated by an entry where length is 0.
In Apple's libunwind implementation the pointer is taken to be to a
single FDE. I suspect this was just an Apple bug, compensated by Apple-
specific code in LLVM.
See lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp and
http://lists.llvm.org/pipermail/llvm-dev/2013-April/061737.html
for more detail.
This change is based on the LLVM RTDyldMemoryManager.cpp. It should
later be changed to be alignment-safe.
Reported by: dim
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8869
Reapply r351610:
Update libunwind custom frame register and deregister functions for
FreeBSD: use the new doubly underscored names for unw_add_dynamic_fde
and unw_remove_dynamic_fde.
NOTE: this should be upstreamed...
Reapply r230021 (by ed):
Add a workaround to prevent endless recursion in compiler-rt.
SPARC and MIPS CPUs don't have special instructions to count
leading/trailing zeroes. The compiler-rt library provides fallback
rountines for these. The 64-bit routines, __clzdi2 and __ctzdi2, are
implemented as simple wrappers around the compiler built-in
__builtin_clz(), assuming these will expand to either 32-bit
CPU instructions or calls to __clzsi2 and __ctzsi2.
Unfortunately, our GCC 4.2 probably thinks that because the operand is
stored in a 64-bit register, it might just be a better idea to invoke
its 64-bit equivalent, simply resulting into endless recursion. Fix this
by defining __builtin_clz and __builtin_ctz to __clzsi2 and __ctzsi2
explicitly.
Reapply r276851:
Update compiler-rt to trunk r224034. This brings a number of new
builtins, and also the various sanitizers. Support for these will be
added in a later commit.
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.
Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.
Fix typo in interp_include() invocation (missing 'p')
Remove setting tftpip, as servip is used by the tftp code in libsa. There
is no separate tftpip global variable any more.
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25897
Update the ng_iface documentation and hooks to reflect the fact that the
node currently only supports IPv4 and v6 packets.
Reviewed by: Lutz Donnerhacke
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25862
This is normally handled by a netgraph thread, but netgraph messages may
be dispatched directly to a node, in which case no VNET is set before
ng_iface calls into the network stack. Netgraph could probably handle
this more generally, but for now just be sure to set the current VNET in
ng_iface.
PR: 242406
Tested by: Michael Muenz <m.muenz@gmail.com>
Reviewed by: Lutz Donnerhacke
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25788
For libc regcomp, this will be a nop. libregex will take this to mean that
it needs to turn off GNU extensions, effectively switching it back to the
POSIX-compliant libc implementation at runtime.
The MALTA kernel config is generally used for QEMU and having support
for VirtIO there by default is quite useful.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D25217
back from the end of the function created an issue.
If one of the routines returns NULL during setup
we have inp's with extra references (which is why
the increment was at the end).
Also the stack switch return code was being ignored
and actually has meaning if the stack cannot take over
it should return NULL.
Fix both of these situation by being sure to test the
return code and of course in any case of return NULL (there
are 3) make sure we properly reduce the ref count.
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D25903
Some folks seem to be hitting issues with build orchestration; presumably
some of our .WAIT-removal optimizations are going awry, and they're ending
up with applications linked against new libc being installed before the new
libc.
Letting installworld complete the first time should ensure that the new libc
is installed by the end of it, then the second installworld will ensure
consistency as everything should succeed.
No functional change.
LK_SLEEPFAIL implies a behavior that is only possible if the lock operation can
sleep. LK_NOWAIT prevents the lock operation from sleeping.
Discussed with: kib
If the buffer identity changed during lookup, sleeping could introduce a
lock order reversal. Since we do not know if the identity changed until we
get the lock, we must try-lock (LK_NOWAIT) only. EINTR and ERESTART error
handling becomes irrelevant, as we no longer sleep.
Reported by: kib
Reviewed by: kib
X-MFC-With: r363482
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D25898
This will be used to remove a magic number in the bhyve AHCI emulation.
Reported by: rpokala
Reviewed by: imp, rpokala
Approved by: imp, rpokala
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D25893
If the destination address has an embedded scope ID, make sure that it
corresponds to a valid ifnet before proceeding. Otherwise a sendto()
with a bogus link-local address can trigger a NULL pointer dereference.
Reported by: syzkaller
Reviewed by: ae
Fixes: r358572
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25887
Almost all consumers use the NDF_ONLY_PNBUF macro, making them avoidably branch
a lot in the NDFREE routine. Also note most of them should not need to call
any cleanup anyway as they don't request HASBUF.
This makes the realpath syscall operational with the new lookup. Note that the
walk to obtain the full path name still takes locks.
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D23917
