rpi_ft5406: Recognize raspberrypi,firmware-ts touchscreen

- Recognize raspberrypi,firmware-ts touchscreen
- Move the driver from ofwbus to simplebus

Reviewed by: manu
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30169

(cherry picked from commit c2c9ef3cedf6d83bdf27308e9e022658cc9b2a08)

Git Hash: c988a558fafe7a361e448c26254d4832ec3fd1ff
Git Author: otis@FreeBSD.org

MFC r344855 (by jhb):

Drop "All rights reserved" from my copyright statements.

Reviewed by: rgrimes
Differential Revision: https://reviews.freebsd.org/D19485

Fix-up for arm, armeb and armv6 builds erroring after r360658, with:

In file included from /usr/src/contrib/compiler-rt/lib/builtins/clear_cache.c:26:
/usr/obj/arm.armv6/usr/src/tmp/usr/include/machine/sysarch.h:95:22: error: unknown type name 'u_int'
int arm_sync_icache (u_int addr, int len);
^

MFC r349887 (by ian):

De-pollute arm's sysarch.h.

Instead of including stdint.h for uintptr_t, include sys/_types.h and use
__types for everything that isn't a native C keyword type.

Remove the #include of cdefs.h. It appears after the include of armreg.h
which has a precondition of cdefs.h being included before it, so everyone
including sysarch.h is already including cdefs.h. (When armv5 support
goes away, there will be no need include armreg.h here either.)

Unfortunately, the unprefixed struct member names "addr" and "len" cannot
be changed, because 3rd-party software is relying on them (libcompiler_rt
is one known consumer).

MFC r358407:

Merge r358406 from the clang1000-import branch:

Fix the following -Werror warning from clang 10.0.0:

sys/arm/arm/identcpu-v6.c:227:5: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (val & CPUV7_CT_CTYPE_RA)
^
sys/arm/arm/identcpu-v6.c:225:4: note: previous statement is here
if (val & CPUV7_CT_CTYPE_WB)
^

This was due to an accidentally inserted tab before the if statement.

MFC r355936, r356045: remove unused kbd drivers

r355936:
Kill off dummy kbd drivers

As far as I can tell, these are an artifact of times when linker sets
couldn't be empty, otherwise the kernel build would fail due to unresolved
symbols. hselasky fixed this in r268138, and I've audited the kbd portions
to make sure nothing would blow up due to the empty linker set and
successfully compiled+ran a kernel with no keyboard support at all.

Kill them off now since they're no longer required.

r356045:
terasic_mtl: kill off final dummy keyboard driver

The rest were removed in r355936, which speculated that the cause of this
phenomenon was due to an inability to have an empty linker set. The comment
included with this one shows that this was, in fact, not the reason.

Regardless, syscons no longer seems to have an issue with not having any
keyboard drivers and in-fact ignores the keyboard probe anyways.

MFC r320001 by zbb:

Fix typo in "Marvell" string

Change Marwell to Marvell

Pointed out by: Ravi Pokala <rpokala@mac.com>
Sponsored by: Rubicon Communications, LLC (Netgate)

MFC r355932: VERSATILEPB: also use default get_fkeystr/diag

In head/, this config was broken from the defaulting commits, but in stable
branches we left the genkbd_* defaults exposed. Do this anyways.

MFC r355206, r355212, r355257, r355271: tty nits

r355206: tty_pts: don't rely on tty header pollution for sys/mutex.h
r355212: tty_rel_gone: add locking assertion
r355257: usb: remove some extraneous tty.h includes
r355271: Remove more needless <sys/tty.h> includes

MFC r355796-r355797, r355799: kbd: defaults for get_fkeystr/diag

The genkbd version of these remains exposed for stable branches, but
keyboard drivers that just want to use the defaults can simply not provide
their own. There shouldn't be any unset in the wild.

r355796:
kbd: provide default implementations of get_fkeystr/diag

Most keyboard drivers are using the genkbd implementations as it is;
formally use them for any that aren't set.

r355797:
chrome_kb: remove default get_fkeystr/diag implementations

This file was missed in r355796, but no harm would have come from this.

r355799:
kbd: patch linker set methods, too

This is needed after r355796. Some double-registration of kbd drivers needs
to be sorted out, then this sysinit will simply add these drivers into the
normal list and kill off any other bits in the driver that are aware of the
linker set, for simplicity.

MFC r355793: kbd drivers: use kbdd_* indirection for diag invocation

MFC rarm: correct kernelstack allocation size

This appears to be a copy-pasto from previous lines that propagated to v6
over the years. Indeed, nothing references kernelstack beyond
USPACE_SVC_STACK_TOP and it would be odd if anything did.

MFC: r351429, r351430, r351485, r351497, r351498

All changes related to disabling Werror on stable/11
to ease MFCs now that we've disabled them in head.

MFC r351618, r351619: exynos5: avoid NULL deref in error case

Reported by: Dr Silvio Cesare of InfoSect
Sponsored by: The FreeBSD Foundation

MFC: r346266
Specify correct Ethernet phy for RPI-B

Approved by: grog, jhb (mentors)

MFC: r346265
Fix cpufreq(4) on RPI-B

Approved by: grog, jhb (mentors)

MFC r346312:

Only set up the interrupts that will actually be used in arm generic_timer.

The code previously set up interrupt handlers for all the interrupt
resources available, including for timers that are not in use. That could
lead to interrupt storms. For example, if boot firmware enabled the virtual
timer but the kernel is using the physical timer, it could get flooded with
interrupts on the virtual timer which it cannot shut off. By only setting
up an interrupt handler for the hardware that will actually be used, any
interrupts from other timer units will remain masked in the interrupt
controller.

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

MFC r345000:

Mark the imx_spi device busy while transfers are in progress, so that the
module can't be unloaded while interrupts are pending.

MFC r342652:

Support the SPI mode and bus clock frequency parameters set by the devices
requesting SPI transfers.

Reported by: SAITOU Toshihide <toshi@ruby.ocn.ne.jp>

MFC r344267:

Add a compatible string to match recent changes in the upstream dts.

MFC r342850:

Add a missing \n to a bootverbose printf.

MFC r336137-r336138, r336202, r336214, r336216

r336137:
Add a manpage for the imx_spi driver.

r336138:
Add pnp info to the imx_spi driver.

r336202:
Enhancements and fixes for the spigen(4) driver...

- Resources used by spigen_mmap_single() are now tracked using
devfs_set_cdevpriv() rather than in the softc.

- Since resources are now tracked per-open-fd, there is no need to try to
impose any exclusive-open logic, so flags related to that are removed.

- Flags used to track open status to prevent detach() when the device is
open are replaced with calls to device_busy()/device_unbusy(). That
extends the protection up the hierarchy so that the spibus and hardware
controller drivers also can't be detached while the device is open/in use.

- Arbitrary limits on the maximum size of a transfer are removed, along with
the sysctl variables that allowed the limits to be changed. There is just
no reason to limit the size of a spi transfer to the machine's page size.
Or to any other arbitrary value, really.

- Most of the locking is removed. It was mostly protecting access to flags
and fields in the softc that no longer exist. The locking that remains is
just to prevent concurrent calls to device_[un]busy().

- The code was calling malloc() with M_WAITOK while holding a mutex in
several places. Since most of the locking is gone, that's fixed.

r336214:
Add various spi devices to NOTES.

r336216:
Actually build and install the spigen.4 manpage.

MFC r336094, r336096

r336094:
Catch up with improvements in RTC handling... It's no longer necessary to
ignore the timestamp passed in to settime() due to inaccuracy, the core
routines now pass in a nanosecond-accurate time freshly-obtained before
calling each driver's settime() method. Also, add calls to the new
debugging output helpers.

r336096:
Make the imx6_snvs driver usable as a module, add pnp info. Add a manpage.

MFC r336079:

Add pnp info to imx6_ahci, and add a module makefile, and a manpage for it.

MFC r333073-r333074

r333073 by manu:
arm: Fix duplicate ahci DRIVER_MODULE

Name each ahci driver uniquely.
This remove the warning printed at each arm boot :
module_register: cannot register simplebus/ahci from kernel; already loaded from kernel

r333074 by manu:
arm: Fix duplicate ehci DRIVER_MODULE

Name each ehci driver uniquely.
This remove the warning printed at each arm boot :
module_register: cannot register simplebus/ehci from kernel; already loaded from kernel

MFC r336070, r336072-r336073, r336076

r336070:
Add pnp info and a module makefile for the imx_wdog watchdog driver.

r336072:
Correctly calculate the value to put in the imx wdog countdown register.

The correct value is seconds*2-1. The code was using just seconds*2, which
led to being off by a half-second -- usually not a big deal, except when the
value was the max (128) it overflowed so zero would get written to the
countdown register, which equates to a timeout of a half second.

r336073:
Add support to the imx watchdog for the FDT "timeout-sec" property, by
automatically initializing the watchdog using the given value. Also,
attach at BUS_PASS_TIMER to extend watchdog protection to more of the
kernel init process.

r336076:
Add a manpage for the imx5/6 watchdog driver.

MFC r335982, r335985, r335988-r335989

r335982:
Fix an out-of-bounds array access... the irq data for teardown is in two
arrays, as elements 0 and 1 of one array and elements 1 and 2 of the other.
Run the loop 0..1 instead of 1..2 and use named constants to offset into
one of the arrays.

PR: 229508

r335985:
Remove a test and early-out which just can't possibly be right. It causes
detach() to do nothing if attach() succeeded, which is the opposite of
what's needed. Also, move device_delete_children() from the end to the
beginning of detach(), so that children won't be trying to make use of the
hardware we're in the process of shutting down.

PR: 229510

r335988:
Add a missing call to usb_bus_mem_free_all() when detaching.

r335989:
Detach all children before beginning to tear down the hardware, instead of
doing it last. Also, remove the local tracking of whether usb's busdma
memory allocation got done, because it's safe to call the free_all
function even if it wasn't.

MFC r335594:

Retrieve the bus clock speed and mode (polarity/phase) from the child device
and set up the hardware accordingly on each transfer. This replaces the old
configuration done via sysctl, and allows both fdt configuration data and
userland control via the spigen device to work.

Submitted by: Bob Frazier
Differential Revision: https://reviews.freebsd.org/D15031

MFC r345757:

Improve debugging options in bcm2835_sdhci.c

Similar to bcm2835_sdhost.c add a TUNABLE and SYSCTL to selectively
turn on debugging printfs if debugging is turned on at compile time.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365.

MFC r306265 (by emaste):

Force LLVM_LIBUNWIND off if we don't have a C++11 compiler

Tested by: bde
Differential Revision: https://reviews.freebsd.org/D7746

MFC r308100 (by emaste):

compile libunwind c source with -fexceptions

When an exception is thrown the unwinder must unwind its own C source
(starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to
be built with unwinding data.

MFC r324998 (by bdrewery):

Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision.

The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used
during the build of world.

Reviewed by: dim, imp
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12792

MFC r329093 (by emaste):

Promote llvm-cov to a standalone option

Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV.
It is intended to provide a superset of the interface and functionality
of gcov.

It is enabled by default when building Clang, similarly to gcov and GCC.

This change moves one file in libllvm to be compiled unconditionally.
Previously it was included only when WITH_CLANG_EXTRAS was set, but the
complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not
worth avoiding a tiny increase in build time.

Reviewed by: dim, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D142645

MFC r331244 (by jhb):

Add support for MIPS to LLVM's libunwind.

This is originally based on a patch from David Chisnall for soft-float
N64 but has since been updated to support O32, N32, and hard-float ABIs.
The soft-float O32, N32, and N64 support has been committed upstream.
The hard-float changes are still in review upstream.

Enable LLVM_LIBUNWIND on mips when building with a suitable (C+11-capable)
toolchain. This has been tested with external GCC for all ABIs and
O32 and N64 with clang.

Reviewed by: emaste
Obtained from: CheriBSD (original N64 patch)
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D14701

MFC r336691 (by emaste):

llvm: remove __FreeBSD_version conditionals

All supported FreeBSD build host versions have backtrace.h, so we can
just eliminate that test. For futimes() we can test the compiler's
built-in __FreeBSD__ major version rather than relying on including
osreldate.h. This should reduce the frequency with which Clang gets
rebuilt when building world.

Reviewed by: dim
Sponsored by: The FreeBSD Foundation

MFC r337379 (by andrew):

Default to armv5te in LINT on arm. This should fix building LINT there.

MFC r337552:

Add optional LLVM BPF target support

BPF (eBPF) is an independent instruction set architecture which is
introduced in Linux a few years ago. Originally, eBPF execute
environment was only inside Linux kernel. However, recent years there
are some user space implementation (https://github.com/iovisor/ubpf,
https://doc.dpdk.org/guides/prog_guide/bpf_lib.html) and kernel space
implementation for FreeBSD is going on
(https://github.com/YutaroHayakawa/generic-ebpf).

The BPF target support can be enabled using WITH_LLVM_TARGET_BPF, as it
is not built by default.

Submitted by: Yutaro Hayakawa <yhayakawa3720@gmail.com>
Reviewed by: dim, bdrewery
Differential Revision: https://reviews.freebsd.org/D16033

MFC r337585:

In r308100, an explicit -fexceptions flag was added for the C sources
from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so.
This is because the unwinder needs the unwinder data for its own
functions.

However, for the C++ sources in libunwind, -fexceptions is already the
default, and this can have the side effect of generating a reference to
__gxx_personality_v0, the so-called personality function, which is
normally provided by the C++ ABI library (libcxxrt or libsupc++).

If the reference ends up in the eventual libgcc_s.so, linking any
non-C++ programs against it will fail with "undefined reference to
`__gxx_personality_v0'".

Note that at high optimization levels, the reference is usually
optimized away, which is why we have never noticed this problem before.

With clang 7.0.0 though, higher optimization levels don't help anymore,
since the addition of address-significance tables [1] in
<https://reviews.llvm.org/rL337339>. Effectively, this always causes a
reference to __gxx_personality_v0.

After discussion with the upstream author of that change, it turns out
that we should compile libunwind sources with the -fno-exceptions
-funwind-tables flags instead. This ensures unwind tables are
generated, but no references to any personality functions are emitted.

[1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html

Reported by: jbeich
PR: 230399

MFC r340287 (by emaste):

Consolidate gcov entries in OptionalObsoleteFiles

Sponsored by: The FreeBSD Foundation

MFC r340289 (by emaste):

llvm-cov: also install as gcov (if GNU gcov is disabled)

llvm-cov provides a gcov-compatible interface when invoked as gcov.

Reviewed by: dim, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17923

MFC r340296 (by emaste):

Move llvm-profdata build into MK_LLVM_COV block

llvm-profdata is used with llvm-cov for code coverage (although llvm-cov
can also operate independently in a gcov-compatible mode).
Although llvm-profdata can be used independently of llvm-cov it makes
sense to group these under one option.

Also handle these in OptionalObsoleteFiles.inc while here.

Sponsored by: The FreeBSD Foundation

MFC r340300 (by emaste):

libllvm: Move SampleProfWriter to SRCS_MIN

It is required by llvm-profdata, now built by default under the
LLVM_COV knob. The additional complexity that would come from avoiding
building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth
the small savings in build time.

Sponsored by: The FreeBSD Foundation

MFC r340972 (by emaste):

llvm-objdump: initial man page

Based on llvm-objdump's online documentation and usage information.
This serves as a starting point; additional detail and cleanup still
required.

Also being submitted upstream in LLVM review D54864. I expect to use
this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we
update to LLVM 8.0 it should be upstream and we will switch to it.

PR: 233437
Reviewed by: bcr (man formatting)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18309

MFC r340973 (by emaste):

llvm-objdump.1: remove invalid options

Some options appear in llvm-objdump's usage information as a side effect
of its option parsing implementation and are not actually llvm-objdump
options. Reported in LLVM review https://reviews.llvm.org/D54864.

Reported by: Fangrui Song
Sponsored by: The FreeBSD Foundation

MFC r340975 (by emaste):

llvm-objdump.1: fix igor / mandoc -Tlint warnings

Accidentally omitted from r340972.

MFC r341055 (by emaste):

llvm-objdump.1: remove more unintentional options

Some options come from static constructors in LLVM libraries and are
automatically added to llvm's usage output. They're not really supposed
to be llvm-objdump options.

Reported by: Fangrui Song in LLVM review D54864
Sponsored by: The FreeBSD Foundation

MFC r344779:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 8.0.0 will soon be available here:
<https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html>
<https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html>
<https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>

PR: 236062
Relnotes: yes

MFC r344798 (by emaste):

libllvm: promote WithColor and xxhash to SRCS_MIN

The armv6 build failed in CI due to missing symbols (from these two
source files) in the bootstrap Clang.

This affected only armv6 because other Clang-using archs are using LLD
as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.

Reported by: CI, via lwhsu
Sponsored by: The FreeBSD Foundation

MFC r344825:

Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise
clang and various other executables will fail to link with undefined
symbols.

Reported by: O. Hartmann <ohartmann@walstatt.org>

MFC r344852:

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

MFC r344896:

Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):

Fix inline assembler constraint validation

The current constraint logic is both too lax and too strict. It fails
for input outside the [INT_MIN..INT_MAX] range, but it also
implicitly accepts 0 as value when it should not. Adjust logic to
handle both correctly.

Differential Revision: https://reviews.llvm.org/D58649

Pull in r355491 from upstream clang trunk (by Hans Wennborg):

Inline asm constraints: allow ICE-like pointers for the "n"
constraint (PR40890)

Apparently GCC allows this, and there's code relying on it (see bug).

The idea is to allow expression that would have been allowed if they
were cast to int. So I based the code on how such a cast would be
done (the CK_PointerToIntegral case in
IntExprEvaluator::VisitCastExpr()).

Differential Revision: https://reviews.llvm.org/D58821

These should fix assertions and errors when using the inline assembly
"n" constraint in certain ways.

In case of devel/valgrind, a pointer was used as the input for the
constraint, which lead to "Assertion failed: (isInt() && "Invalid
accessor"), function getInt".

In case of math/secp256k1, a very large integer value was used as input
for the constraint, which lead to "error: value '4624529908474429119'
out of range for constraint 'n'".

PR: 236216, 236194

MFC r344951:

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version
numbers.

PR: 236062

MFC r345018:

Merge LLVM libunwind trunk r351319, from just before upstream's
release_80 branch point. Afterwards, we will merge the rest of the
changes in the actual release_80 branch.

PR: 236062

MFC r345019:

Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).

PR: 236062

MFC r345021:

Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):

[RegAlloc] Avoid compile time regression with multiple copy hints.

As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive
compile time building opencollada"), this patch makes sure that no
phys reg is hinted more than once from getRegAllocationHints().

This handles the case were many virtual registers are assigned to the
same physreg. The previous compile time fix (r343686) in
weightCalcHelper() only made sure that physical/virtual registers are
passed no more than once to addRegAllocationHint().

Review: Dimitry Andric, Quentin Colombet
https://reviews.llvm.org/D59201

This should fix a hang when compiling certain generated .cpp files in
the graphics/opencollada port.

PR: 236313

MFC r345068 (by jhb):

Move libunwind out of contrib/llvm/projects.

Move LLVM's libunwind to its own contrib/ directory similar to other
runtime libraries like libc++ and libcxxrt.

Reviewed by: dim, emaste
Differential Revision: https://reviews.freebsd.org/D19534

MFC r345073:

Revert r308867 (which was originally committed in the clang390-import
project branch):

Work around LLVM PR30879, which is about a bad interaction between
X86 Call Frame Optimization on i386 and libunwind, by disallowing the
optimization for i386-freebsd12.

This should fix some instances of broken exception handling when
frame pointers are omitted, in particular some unittests run during
the build of editors/libreoffice.

This hack will be removed as soon as upstream has implemented a more
permanent fix for this problem.

And indeed, after r345018 and r345019, which updated LLVM libunwind to
the most recent version, the above workaround is no longer needed. The
upstream commit which fixed this is:

https://llvm.org/viewvc/llvm-project?view=revision&revision=292723

Specifically, 32 bit (i386-freebsd) executables optimized with omitted
frame pointers and Call Frame Optimization should now behave correctly
when a C++ exception is thrown, and the stack is unwound.

Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879
PR: 236062

MFC r345152:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb
release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts,
and bump version numbers.

PR: 236062

MFC r345231:

Add LLVM openmp trunk r351319 (just before the release_80 branch point)
to contrib/llvm. This is not yet connected to the build, the glue for
that will come in a follow-up commit.

PR: 236062

MFC r345232:

Bootstrap svn:mergeinfo on contrib/openmp.

PR: 236062

MFC r345233:

Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).

PR: 236062

MFC r345234:

Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3).
This has also been submitted upstream.

PR: 236062

MFC r345283:

Enable building libomp.so for 32-bit x86. This is done by selectively
enabling the functions that save and restore MXCSR, since access to this
register requires SSE support.

Note that you may run into other issues with OpenMP on i386, since this
*not* yet supported upstream, and certainly not extensively tested.

PR: 236062, 236582

MFC r345345:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365. There were no functional changes since the
most recent merge, of 8.0.0 rc5.

Release notes for llvm, clang, lld and libc++ 8.0.0 are now available:

https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html

PR: 236062

MFC r345349:

Pull in r352826 from upstream lld trunk (by Fangrui Song):

[ELF] Support --{,no-}allow-shlib-undefined

Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when
linking an executable. This patch implements a check to error on
undefined symbols in a shared object, if all of its DT_NEEDED entries
are seen.

Our approach resembles the one used in gold, achieves a good balance
to be useful but not too smart (ld.bfd traces all DSOs and emulates
the behavior of a dynamic linker to catch more cases).

The error is issued based on the symbol table, different from
undefined reference errors issued for relocations. It is most
effective when there are DSOs that were not linked with -z defs (e.g.
when static sanitizers runtime is used).

gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: joerg, emaste, arichardson, llvm-commits

Differential Revision: https://reviews.llvm.org/D57385

Pull in r352943 from upstream lld trunk (by Fangrui Song):

[ELF] Default to --no-allow-shlib-undefined for executables

Summary:
This follows the ld.bfd/gold behavior.

The error check is useful as it captures a common type of ld.so
undefined symbol errors as link-time errors:

// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }

// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }

// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: llvm-commits, emaste, arichardson

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57569

Together, these add support for --no-allow-shlib-undefined, and make it
the default for executables, so they will fail to link if any symbols
from needed shared libraries are undefined.

Reported by: jbeich
PR: 236062, 236141

MFC r345449:

Pull in r356809 from upstream llvm trunk (by Eli Friedman):

[ARM] Don't form "ands" when it isn't scheduled correctly.

In r322972/r323136, the iteration here was changed to catch cases at
the beginning of a basic block... but we accidentally deleted an
important safety check. Restore that check to the way it was.

Fixes https://bugs.llvm.org/show_bug.cgi?id=41116

Differential Revision: https://reviews.llvm.org/D59680

This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking
is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe
port for armv7.

PR: 236062, 236568