MFC: r292180 (partial), r297127 (partial), r311911, r311923, r312939,
r313250, r313712, r314811 (partial), r314887 (partial), r315430,
r317981, r315466

o Move the DRIVER_MODULE() statements that declare mmc(4) to be a child
of the various bridge drivers out of dev/mmc.c and into the bridge
drivers.

o Add ACPI platform support for SDHCI driver.

o Fix some overly long lines, whitespace and other bugs according to
style(9) as well as spelling etc. in mmc(4), mmcsd(4) and sdhci(4).

o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method,
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.

o Trim/adjust includes.

o Add and use a MMC_DECLARE_BRIDGE macro for declaring mmc(4) bridges
as kernel drivers and their dependency onto mmc(4).

o Add support for eMMC "partitions". Besides the user data area, i. e.
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)

Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.

CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.

o Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications.

o Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter have been added to ports as sysutils/mmc-utils.
Among others, the `mmc` tool of mmc-utils allows for partitioning
eMMC devices (tested working).

o For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.

o Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.

MFC 308664,308742,308743

308664
hyperv/vss: Add driver and tools for VSS

VSS stands for "Volume Shadow Copy Service". Unlike virtual machine
snapshot, it only takes snapshot for the virtual disks, so both
filesystem and applications have to aware of it, and cooperate the
whole VSS process.

This driver exposes two device files to the userland:

/dev/hv_fsvss_dev

Normally userland programs should _not_ mess with this device file.
It is currently used by the hv_vss_daemon(8), which freezes and
thaws the filesystem. NOTE: currently only UFS is supported, if
the system mounts _any_ other filesystems, the hv_vss_daemon(8)
will veto the VSS process.

If hv_vss_daemon(8) was disabled, then this device file must be
opened, and proper ioctls must be issued to keep the VSS working.

/dev/hv_appvss_dev

Userland application can opened this device file to receive the
VSS freeze notification, hold the VSS for a while (mainly to flush
application data to filesystem), release the VSS process, and
receive the VSS thaw notification i.e. applications can run again.

The VSS will still work, even if this device file is not opened.
However, only filesystem consistency is promised, if this device
file is not opened or is not operated properly.

hv_vss_daemon(8) is started by devd(8) by default. It can be disabled
by editting /etc/devd/hyperv.conf.

Submitted by: Hongjiang Zhang <honzhan microsoft com>
Reviewed by: kib, mckusick
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8224

308742
hyperv/vss: Nuke unused variables.

Submitted by: markj
Reported by: markj
Sponsored by: Microsoft

308743
hyperv/vss: Install the userland daemon to /usr/sbin instead of /

Submitted by: markj
Reported by: markj
Sponsored by: Microsoft

MFC r275907:

r275907 (by ngie):

Fix building/installing tests when TESTSBASE != /usr/tests

The work in r258233 hardcoded the assumption that tests was the last component
of the tests tree by pushing tests as an explicit prefix for the paths in
BSD.tests.dist and /usr was the prefix for all tests, per BSD.usr.dist and all
of the mtree calls used in Makefile.inc1. This assumption breaks if/when one
provides a custom TESTSBASE "prefix", e.g. TESTSBASE=/mytests .

One thing that r258233 did properly though was remove "/usr/tests" creation
from BSD.usr.dist -- that should have not been there in the first place. That
was an "oops" on my part for the work that was originally committed in r241823

Phabric: D1301
Reviewed by: imp
Sponsored by: EMC / Isilon Storage Division

MFC r265925:

Upgrade our copy of llvm/clang to 3.4.1 release. This release contains
mostly fixes, for the following upstream bugs:

http://llvm.org/PR16365 http://llvm.org/PR17473 http://llvm.org/PR18000
http://llvm.org/PR18068 http://llvm.org/PR18102 http://llvm.org/PR18165
http://llvm.org/PR18260 http://llvm.org/PR18290 http://llvm.org/PR18316
http://llvm.org/PR18460 http://llvm.org/PR18473 http://llvm.org/PR18515
http://llvm.org/PR18526 http://llvm.org/PR18600 http://llvm.org/PR18762
http://llvm.org/PR18773 http://llvm.org/PR18860 http://llvm.org/PR18994
http://llvm.org/PR19007 http://llvm.org/PR19010 http://llvm.org/PR19033
http://llvm.org/PR19059 http://llvm.org/PR19144 http://llvm.org/PR19326

MFC 261991:

Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.

The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>

MFC 262121 (by emaste):

Update lldb for clang/llvm 3.4 import

This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.

Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175

Sponsored by: DARPA, AFRL

MFC 262186 (by emaste):

Fix mismerge in r262121

A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.

MFC 262303:

Pull in r197521 from upstream clang trunk (by rdivacky):

Use the integrated assembler by default on FreeBSD/ppc and ppc64.

Requested by: jhibbits

MFC 262611:

Pull in r196874 from upstream llvm trunk:

Fix a crash that occurs when PWD is invalid.

MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.

The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.

If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.

The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.

This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.

Reported by: decke

MFC 262809:

Pull in r203007 from upstream clang trunk:

Don't produce an alias between destructors with different calling conventions.

Fixes pr19007.

(Please note that is an LLVM PR identifier, not a FreeBSD one.)

This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.

Reported by: multiple users on freebsd-current
PR: bin/187103

MFC 263048:

Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.

Apparently some versions of CMake still rely on this archaic feature...

Reported by: rakuco

MFC 263049:

Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.

Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.

Bulk sync of pf changes from head, in attempt to fixup broken build I
made in r263029.

Merge r257186,257215,257349,259736,261797.

These changesets split pfvar.h into several smaller headers and make
userland utilities to include only some of them.

MFC r261283:

Import libc++ 3.4 release. This contains a lot of bugfixes, and some
preliminary support for C++1y.

MFC r261604:

HEAD is not buildable for the past day. Commit a 'quick fix' in order to permit
buildworld to complete.

Reviewed by: theraven

MFC r261608:

Apply a cleaner solution for the sign warnings that can occur when
compiling libc++'s <locale> header with -Wsystem-headers on.

This has also been submitted upstream.

Reported by: asomers

MFC r261801:

An ABI incompatibility crept into the libc++ 3.4 import in r261283. It
was caused by upstream libc++ commit r194536, which aimed to make the
headers more standards-compliant, by making std::pair's copy constructor
trivial. Unfortunately, this could cause certain C++ applications using
shared libraries built against the previous version of libc++ to crash.

Fix the ABI incompatibility by making std::pair's copy constructor
non-trivial again.

Please note: Any C++ applications or shared libraries built with libc++
between r261283 and this revision should be recompiled.

Reported by: stefanf

Plug the ATF tests into the build.

This is a MFC into stable/10 of:
- r257849 Add libatf-c++ to the prebuild libs.
- r257853 Build and install the atf tests.
- r258233 Move all atf directories to the tests mtree.
- r258285 Fix the build of some ATF tests.

This change is "make tinderbox" clean on ref10-amd64 with the default
settings of WITHOUT_TESTS. It is likely for the WITH_TESTS build to
still be broken because not all relevant changes have been merged yet.

MFC r275907:

r275907 (by ngie):

Fix building/installing tests when TESTSBASE != /usr/tests

The work in r258233 hardcoded the assumption that tests was the last component
of the tests tree by pushing tests as an explicit prefix for the paths in
BSD.tests.dist and /usr was the prefix for all tests, per BSD.usr.dist and all
of the mtree calls used in Makefile.inc1. This assumption breaks if/when one
provides a custom TESTSBASE "prefix", e.g. TESTSBASE=/mytests .

One thing that r258233 did properly though was remove "/usr/tests" creation
from BSD.usr.dist -- that should have not been there in the first place. That
was an "oops" on my part for the work that was originally committed in r241823

Phabric: D1301
Reviewed by: imp
Sponsored by: EMC / Isilon Storage Division

MFC r265925:

Upgrade our copy of llvm/clang to 3.4.1 release. This release contains
mostly fixes, for the following upstream bugs:

http://llvm.org/PR16365 http://llvm.org/PR17473 http://llvm.org/PR18000
http://llvm.org/PR18068 http://llvm.org/PR18102 http://llvm.org/PR18165
http://llvm.org/PR18260 http://llvm.org/PR18290 http://llvm.org/PR18316
http://llvm.org/PR18460 http://llvm.org/PR18473 http://llvm.org/PR18515
http://llvm.org/PR18526 http://llvm.org/PR18600 http://llvm.org/PR18762
http://llvm.org/PR18773 http://llvm.org/PR18860 http://llvm.org/PR18994
http://llvm.org/PR19007 http://llvm.org/PR19010 http://llvm.org/PR19033
http://llvm.org/PR19059 http://llvm.org/PR19144 http://llvm.org/PR19326

MFC 261991:

Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.

The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>

MFC 262121 (by emaste):

Update lldb for clang/llvm 3.4 import

This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.

Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175

Sponsored by: DARPA, AFRL

MFC 262186 (by emaste):

Fix mismerge in r262121

A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.

MFC 262303:

Pull in r197521 from upstream clang trunk (by rdivacky):

Use the integrated assembler by default on FreeBSD/ppc and ppc64.

Requested by: jhibbits

MFC 262611:

Pull in r196874 from upstream llvm trunk:

Fix a crash that occurs when PWD is invalid.

MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.

The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.

If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.

The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.

This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.

Reported by: decke

MFC 262809:

Pull in r203007 from upstream clang trunk:

Don't produce an alias between destructors with different calling conventions.

Fixes pr19007.

(Please note that is an LLVM PR identifier, not a FreeBSD one.)

This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.

Reported by: multiple users on freebsd-current
PR: bin/187103

MFC 263048:

Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.

Apparently some versions of CMake still rely on this archaic feature...

Reported by: rakuco

MFC 263049:

Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.

Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.

Bulk sync of pf changes from head, in attempt to fixup broken build I
made in r263029.

Merge r257186,257215,257349,259736,261797.

These changesets split pfvar.h into several smaller headers and make
userland utilities to include only some of them.

MFC r261283:

Import libc++ 3.4 release. This contains a lot of bugfixes, and some
preliminary support for C++1y.

MFC r261604:

HEAD is not buildable for the past day. Commit a 'quick fix' in order to permit
buildworld to complete.

Reviewed by: theraven

MFC r261608:

Apply a cleaner solution for the sign warnings that can occur when
compiling libc++'s <locale> header with -Wsystem-headers on.

This has also been submitted upstream.

Reported by: asomers

MFC r261801:

An ABI incompatibility crept into the libc++ 3.4 import in r261283. It
was caused by upstream libc++ commit r194536, which aimed to make the
headers more standards-compliant, by making std::pair's copy constructor
trivial. Unfortunately, this could cause certain C++ applications using
shared libraries built against the previous version of libc++ to crash.

Fix the ABI incompatibility by making std::pair's copy constructor
non-trivial again.

Please note: Any C++ applications or shared libraries built with libc++
between r261283 and this revision should be recompiled.

Reported by: stefanf

Plug the ATF tests into the build.

This is a MFC into stable/10 of:
- r257849 Add libatf-c++ to the prebuild libs.
- r257853 Build and install the atf tests.
- r258233 Move all atf directories to the tests mtree.
- r258285 Fix the build of some ATF tests.

This change is "make tinderbox" clean on ref10-amd64 with the default
settings of WITHOUT_TESTS. It is likely for the WITH_TESTS build to
still be broken because not all relevant changes have been merged yet.