From owner-freebsd-toolchain@freebsd.org Mon Aug 1 21:40:29 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15505BAB317
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Mon, 1 Aug 2016 21:40:29 +0000 (UTC)
(envelope-from carpeddiem@gmail.com)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com
[IPv6:2607:f8b0:4001:c0b::22f])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id D4A7A1D6E
for <freebsd-toolchain@freebsd.org>; Mon, 1 Aug 2016 21:40:28 +0000 (UTC)
(envelope-from carpeddiem@gmail.com)
Received: by mail-it0-x22f.google.com with SMTP id j124so185612370ith.1
for <freebsd-toolchain@freebsd.org>; Mon, 01 Aug 2016 14:40:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:from:date:message-id:subject:to
:content-transfer-encoding;
bh=3M31D53slzTYxWhYaS5/bHmxo+Sxuww85hv1WXfg7rE=;
b=k3V5RX4LY25juNMbYUhKT9Ucq1GxttZGbdyh0/VJWVdlmd5hWCNIveJwtBroEu+zaR
r95BYmyG0bkFkCIuZudXr3O53rFKl2M2pa90SzwE7osZd71WR3hqeTYdUe6fJxIBzkSF
Carbbj4RTlDzvMfoAT+jABf9q9caLfikZH2DH4XXJig8IshZiSmaXqOSM8HFApGG2EE6
oeZtTiQXT630gV0znqhWesb8Yaxqe5N4+uzLWpBqFqyXQGIpCbd1eyRShzAQ+goAAfSk
DG1aBfTCpDUFOASbyv4hTec0C9sTS9CcBtDLwHqg4IFkixOGIe9Wr6f3c7Fq+yDsfV5j
K1xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
:to:content-transfer-encoding;
bh=3M31D53slzTYxWhYaS5/bHmxo+Sxuww85hv1WXfg7rE=;
b=STBVLIpLz4/IkUpPi1+t1NBVDOCbuJFbaEhrL+vVoTvKNz2WSOeBowPllCM9QcK6Zk
7teuh4kzbS5o2x3QTkbgIvGOJnhOVFtVHnd89TxqbglSNcxe6BQgZscka+aOAqzeaCTp
RldAjgHM6PBUyvJ+Ud+SiKy+xjkflsCvBhtMeJD0DbgAf1B2W6t+RngvyNbasiAUIpZS
Qsf6Jn7u0zN/eILfnOKMyhG8DjLt2KWSe3OXWDfw9FV9qQUgAlHSPo+2ZXiW2/9uI2WW
kjqAOzRhtyGxE5RXR9O1jbUi+mX7y9XgwsakELgRo9vDl62TRKQfJUe9cs1Rq+S9fqjQ
2xgA==
X-Gm-Message-State: AEkoous/vUAjOitURHwlLOh8zTtmmwOp/AVUqCVpB34x0VTBKl8ACiB6MwrulGD9BwkY7lU5Doq3V0UzBsqofw==
X-Received: by 10.36.86.134 with SMTP id o128mr63373879itb.5.1470087628002;
Mon, 01 Aug 2016 14:40:28 -0700 (PDT)
MIME-Version: 1.0
Sender: carpeddiem@gmail.com
Received: by 10.107.138.28 with HTTP; Mon, 1 Aug 2016 14:40:07 -0700 (PDT)
From: Ed Maste <emaste@freebsd.org>
Date: Mon, 1 Aug 2016 17:40:07 -0400
X-Google-Sender-Auth: op7nd7ahyYIsdlOfGRorcQT_9X8
Message-ID: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
Subject: Update on using LLVM's lld linker in the FreeBSD base system
To: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2016 21:40:29 -0000
Over the past year or so I have been investigating the state of LLVM's
lld linker for use in the FreeBSD base system, to see if it could be
used as FreeBSD's system linker.
Why do we need a new linker? Compared to the GNU ld 2.17.50 that we
have in the FreeBSD base system, lld will bring:
* AArch64 (arm64) support
* Link Time Optimization (LTO)
* New ABI support
* Other linker optimization
* Much faster link times
* Maintained code base
I've posted a couple of status updates on the LLVM mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html
http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html
Since the last update in March several lld developers have implemented
much of the missing functionality. The main blockers were symbol
version support and expression evaluation in the linker script
expression parser. Both are now nearly complete.
There are a few features used by the FreeBSD base system that lld
developers (intentionally) do not expect to implement, unless they're
reasonably widely used in a variety of different software. If they're
not implemented we can modify FreeBSD to avoid using them. I'm aware
of:
-N/--omagic, used by some boot loader components. We can achieve the
same effect with a linker script.
-dc, used by the rescue build. As long as object files are built
specifically for rescue we can probably use -fno-common instead.
-r binary to convert binary files into ELF objects, used by some
device drivers in kernel and module builds. We can use
objcopy(elfcopy) instead.
Davide Italiano and Rafael =C3=81vila de Esp=C3=ADndola presented an update=
on
the state of lld at BSDCan 2016:
https://www.bsdcan.org/2016/schedule/events/656.en.html
At this point I'm confident that lld is going to be a viable linker
for the FreeBSD base system, and am beginning to plan its import.
I expect the process will look something like this:
1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
on the same architectures that use Clang (amd64, arm, arm64, i386). I
don't think there's a need for a WITH_LLD src.conf knob, but will add
one if desired.
3. Update lld again (most likely to a snapshot from upstream SVN) once
it is able to link an unmodified FreeBSD kernel.
4. Modify the boot loader and kernel builds to avoid using features
not implemented by lld.
5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
hardlink instead of /usr/bin/ld.bfd.
6. Request ports exp-runs and issue a call for testing with 3rd party
software. Fix issues found during this process.
7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
There is (some) support for mips and powerpc in lld, but I'm not sure
how well tested it is. RISC-V is not yet supported but there is a
desire to have a full LLVM-based RISC-V toolchain. I'm not aware of
any plan with respect to sparc64 in lld. In any case, I do not plan to
address these architectures in the initial lld work. In the near term
they will continue to use GNU ld 2.17.50.
I'm interested in your comments, questions and concerns about this plan.
From owner-freebsd-toolchain@freebsd.org Mon Aug 1 22:27:19 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8816BAC3BA
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Mon, 1 Aug 2016 22:27:19 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com
[IPv6:2607:f8b0:4001:c0b::22b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id A238B11EC
for <freebsd-toolchain@freebsd.org>; Mon, 1 Aug 2016 22:27:19 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: by mail-it0-x22b.google.com with SMTP id f6so257374798ith.1
for <freebsd-toolchain@freebsd.org>; Mon, 01 Aug 2016 15:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=CVxiwHmcCh2hHuNCCX1sLjkLTT5DsUWfr9HstkffC/Y=;
b=Lj26jogi0xRuz+YOemXsEKNde2yVEDeZDwTEpQhfOJ6Jk6DIit3VmTQf3C0Prc+zO7
w8HGWvEynciJw4fQDoj4cHV/zuCb4APVITgySc+YOZRRRecRuO994gGnliXh0MLBqFQF
Eo9+BI7P8abwOpa953/xEIEhx2kM41C560thC/MNWxAkg+wqWHdi6d5gZJnYPymargsP
jy54S1SPJLGf/gO/byGyaZTqWU697/OsbnPV1oO3vBAqZNfhoaNFcyRbpKdjM6r243CY
41JypWWhOiq+x8xJMU0sKf4Ns8dCJQAzKu7xW0Ga+hKBxqn7Kj9yfbKDU3MC0EIr/n4N
QdVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=CVxiwHmcCh2hHuNCCX1sLjkLTT5DsUWfr9HstkffC/Y=;
b=eoqV/TQwojC2LHsh8dx4RGpKUZOrqklYI4mz4S/+p0/7RBMNX6JL/6MW1Kh67//wWk
ECEXvVmSRybrZ7WwjyMfe5knW25giawNS1orOXlSSy9lVoe4qQzmVC5v6652V5OS33CL
BgUPAgJTB9OunoIRcslRSreD+7b0WoXUWub0TgNEHAJC/HuYPUQiq/IwQtUWG9dVVcGw
wabnumZaOkCb6sKMls7qHs7pAkLxmPJwf+3k0o8VFK/8zTZNCxrJiMhpRqZLRS+rEOI3
cUXrSIYUrFxDz0F2mnqAThkq/GqjcgksaHyY4SAHGb/9BHhPlsiuNnqOYK4mBS7Rzkks
yZog==
X-Gm-Message-State: AEkoouu8d23RAubM5EIKhPFg/byh+hRVHqMWh5TgnbhjKbCEq+G7WUAo7NiQ9pqPj7e/zOWHz/N4rAlpPqb7fQ==
X-Received: by 10.36.39.195 with SMTP id g186mr55343822ita.53.1470090438981;
Mon, 01 Aug 2016 15:27:18 -0700 (PDT)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.79.137.131 with HTTP; Mon, 1 Aug 2016 15:27:18 -0700 (PDT)
X-Originating-IP: [69.53.245.200]
In-Reply-To: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
References: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 1 Aug 2016 16:27:18 -0600
X-Google-Sender-Auth: sUBsNtZY-EXrvG_5SKoh2j1f2hI
Message-ID: <CANCZdfq7UfHT+yMxDDPA_E2iWYh57GjJPB-sML_+J7qbmRhpzw@mail.gmail.com>
Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system
To: Ed Maste <emaste@freebsd.org>
Cc: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2016 22:27:19 -0000
On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste <emaste@freebsd.org> wrote:
> -N/--omagic, used by some boot loader components. We can achieve the
> same effect with a linker script.
Agreed. Or objcopy even.
> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
> on the same architectures that use Clang (amd64, arm, arm64, i386). I
> don't think there's a need for a WITH_LLD src.conf knob, but will add
> one if desired.
I'm on the fence here. Since it is ld.lld, I'm not sure there's much value
here so long as it falls under one of the clang WITH/WITHOUT symbols.
> 4. Modify the boot loader and kernel builds to avoid using features
> not implemented by lld.
This can be done in parallel starting now. I may take a stab at the boot
loader bits since I think that will be easy.
> 6. Request ports exp-runs and issue a call for testing with 3rd party
> software. Fix issues found during this process.
Experience suggests this may be the long poll :)
> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
For the WITH/WITHOUT things, this is just a matter of changing the default
MK_foo setting, right?
> There is (some) support for mips and powerpc in lld, but I'm not sure
> how well tested it is. RISC-V is not yet supported but there is a
> desire to have a full LLVM-based RISC-V toolchain. I'm not aware of
> any plan with respect to sparc64 in lld. In any case, I do not plan to
> address these architectures in the initial lld work. In the near term
> they will continue to use GNU ld 2.17.50.
OK. How does this square up against the gcc 4.2 removal timelines and
plans? Once gcc is gone, we'll have to use an external toolchain anyway
to build mips at least (though clang is close, it isn't there yet despite Sean
Bruno's wonderful work).
> I'm interested in your comments, questions and concerns about this plan.
What's the timeline for all this stuff, do you think?
Generally, I like it though. My concerns are mostly with ports and gcc plans.
Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan
for both before we get out the axes. Note this is purely a timing argument,
not whether to get them out, just when :)
Warner
From owner-freebsd-toolchain@freebsd.org Tue Aug 2 00:07:09 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44992BA204B
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 2 Aug 2016 00:07:09 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-211-170.reflexion.net
[208.70.211.170])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id AAD601BA0
for <freebsd-toolchain@freebsd.org>; Tue, 2 Aug 2016 00:07:08 +0000 (UTC)
(envelope-from markmi@dsl-only.net)
Received: (qmail 9273 invoked from network); 2 Aug 2016 00:06:08 -0000
Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1)
by 0 (rfx-qmail) with SMTP; 2 Aug 2016 00:06:08 -0000
Received: by rtc-sm-01.app.dca.reflexion.local
(Reflexion email security v7.90.6) with SMTP;
Mon, 01 Aug 2016 20:06:12 -0400 (EDT)
Received: (qmail 11069 invoked from network); 2 Aug 2016 00:06:12 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Aug 2016 00:06:12 -0000
X-No-Relay: not in my network
Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net
[70.189.131.151])
by iron2.pdx.net (Postfix) with ESMTPSA id 07D7E1C407B
for <freebsd-toolchain@freebsd.org>; Mon, 1 Aug 2016 17:05:54 -0700 (PDT)
From: Mark Millard <markmi@dsl-only.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system
Message-Id: <2854CBD7-0DA7-4363-967B-6A1566156D4C@dsl-only.net>
Date: Mon, 1 Aug 2016 17:06:05 -0700
To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 00:07:09 -0000
Warner Losh imp at bsdimp.com wrote on Aug 1 22:27:19 UTC 2016 :
> On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste <emaste at freebsd.org> =
wrote:
>=20
> > There is (some) support for mips and powerpc in lld, but I'm not =
sure
> > how well tested it is. RISC-V is not yet supported but there is a
> > desire to have a full LLVM-based RISC-V toolchain. I'm not aware of
> > any plan with respect to sparc64 in lld. In any case, I do not plan =
to
> > address these architectures in the initial lld work. In the near =
term
> > they will continue to use GNU ld 2.17.50.
>=20
> OK. How does this square up against the gcc 4.2 removal timelines and
> plans? Once gcc is gone, we'll have to use an external toolchain =
anyway
> to build mips at least (though clang is close, it isn't there yet =
despite Sean
> Bruno's wonderful work).
This note is about the status for TARGET_ARCH=3Dpowerpc and =
TARGET_ARCH=3Dpowerpc64.
clang 3.8.0 is not ready for TARGET_ARCH=3Dpowerpc or =
TARGET_ARCH=3Dpowerpc64 yet.
(I do not know about clang/clang++ 3.9 or later.) So this is another =
external
tool chain family (so far).
clang/clang++ for TARET_ARCH=3Dpowerpc does not even generate code for =
the FreeBSD
specified ABI's stack handling properties: It requires a so-called =
red-zone for
signal handling because of when the stack pointer is adjusted for both =
directions.
clang also does not handle some of the assembler notation that is used =
in the kernel.
Neither TARGET_ARCH variant handles C++ exceptions correctly for things =
built via
clang++ 3.8.0.
TARGET_ARCH=3Dpowerpc64 is missing soft-float support, blocking building =
libstand as
I remember.
There is more wrong. See https://llvm.org/bugs/show_bug.cgi?id=3D25780 :
[META] Using Clang as the FreeBSD/ppc system compiler
And its "Depends on" list. There are about 6 reports pending.
Additional clang related notes:
TARGET_ARCH=3Dpowerpc notes: with a kernel modified to have signal =
handling provide a
red-zone I've been able to use clang for buildworld and run a system =
that is a
mix of a gcc 4.2.1 based kernel and a clang 3.8.0 based world. But I =
have to avoid
using things that would use C++ exception handling if built via the =
system clang++
3.8.0.
TARGET_ARCH=3Dpowerpc64 note: I've never got that far with clang 3.8.0.
xtoolchain related notes:
There is no external toolchain in place for TARGET_ARCH=3Dpowerpc that I =
know of.
I do build TARGET_ARCH=3Dpowerpc64 via devel/powerpc64-gcc and
devel/powerpc64-xtoolchain-gcc . But I've never gotten lib32 to work
when built from that toolchain so I normally do not build lib32:
crtbeginS code problem(s) from not matching the register usage.
Where my mostly TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 source =
changes
are:
# svnlite status /usr/src/
M =
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
M /usr/src/lib/csu/powerpc64/Makefile
? /usr/src/sys/amd64/conf/GENERIC-NODBG
? /usr/src/sys/amd64/include/include
? /usr/src/sys/arm/conf/RPI2-NODBG
? /usr/src/sys/arm/include/include
M /usr/src/sys/boot/ofw/Makefile.inc
M /usr/src/sys/boot/powerpc/Makefile.inc
M /usr/src/sys/boot/powerpc/kboot/Makefile
M /usr/src/sys/boot/uboot/Makefile.inc
M /usr/src/sys/conf/Makefile.powerpc
M /usr/src/sys/conf/kern.mk
M /usr/src/sys/conf/kmod.mk
? /usr/src/sys/powerpc/conf/GENERIC64-NODBG
? /usr/src/sys/powerpc/conf/GENERIC64vtsc
? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG
? /usr/src/sys/powerpc/conf/GENERICvtsc
? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG
? /usr/src/sys/powerpc/include/include
M /usr/src/sys/powerpc/ofw/ofw_machdep.c
M /usr/src/sys/powerpc/powerpc/exec_machdep.c
? /usr/src/sys/x86/include/include
(Something along the way made the include/include's, with the nested
one pointing to its parent one. I did not explicitly do this.)
Some of the .c source changes are tied to my making PowerMac G5's boot
reliably when they have lots of RAM. (Just experimentally derived and
observed on the G5 examples that I sometimes have access to.)
I build with both vt and sc enabled and PS3 disabled.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
From owner-freebsd-toolchain@freebsd.org Tue Aug 2 04:19:57 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81606BACD07
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 2 Aug 2016 04:19:57 +0000 (UTC)
(envelope-from carpeddiem@gmail.com)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com
[IPv6:2607:f8b0:4001:c0b::236])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4AFF61E97
for <freebsd-toolchain@freebsd.org>; Tue, 2 Aug 2016 04:19:57 +0000 (UTC)
(envelope-from carpeddiem@gmail.com)
Received: by mail-it0-x236.google.com with SMTP id f6so189943754ith.0
for <freebsd-toolchain@freebsd.org>; Mon, 01 Aug 2016 21:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=dtwFuMtSwHU5zelmwSx76VP7a5uCwcD4Q9BaI8BeqrA=;
b=jQ7jOuh0rGMU8/FukRAAWnVJ0jSsEOTL4nLkVd/KxMDsiwCzG9MFKDKII2emNA2ax+
sJlHKXW3Du/VUAvuJinv+0WnsCH++QZKVddaras63l3lbV7X6B+UK7K5OCQvIlWjnZLm
ZnaFYPxqaWbX3cwk7aZnGC1xsG5Afls4pPwpaDh4bm45swJi70l3tqAhIlrPhUilZQcK
HSStuxDuyYF/aTHrnzV+vjuV+76DbS4IRWG47MjOiFVJseXuSEGrKZFw9sEzmcITCA/I
CyIxJbBKpNIsXnPXpfBO/QiWHS/aKg/EXCpqX7bwPLc+aLdfbMLK0ih9/Y7dVQepY64u
OBKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=dtwFuMtSwHU5zelmwSx76VP7a5uCwcD4Q9BaI8BeqrA=;
b=ekevSK3yIyqLWhhKW0T7I8g0G5Oa60O6QEdK2L9bK52JWXOPJRocYay+H7L631L9V7
iGECHln/ufincRxhpZfX27O7GrXlNmXqhpPUwGgJ500O/v0P0A6xsW8FZkFuPFXLVzAw
xn42hXNf3I6+2bJTj4Sen21PaeJ/6DiCGjjU56J+rHintDO5+Tyf6aW7w4T6V3vpRT26
6YCCkvOFJpwLvqtmg8nbBybD5LOv8PlN8o02/xbz6a7b0souSzrWuVAVh10bV6kUP7B2
yyye6P4fBqwDrv6cQtdLnubep+Vn7xDRIAgGKQufPZWvWAKCoAbMbU5kmSlKMf8b/TOo
LsTQ==
X-Gm-Message-State: AEkoousK6fficWhOtHsReZW0uwU/jc3i6xRmZaClmEuv9I7IfOjAr/HD6a80o1BgXInWISQvx+AzJVlE1bRPlw==
X-Received: by 10.36.86.134 with SMTP id o128mr64743142itb.5.1470111596493;
Mon, 01 Aug 2016 21:19:56 -0700 (PDT)
MIME-Version: 1.0
Sender: carpeddiem@gmail.com
Received: by 10.107.138.28 with HTTP; Mon, 1 Aug 2016 21:19:36 -0700 (PDT)
In-Reply-To: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
References: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
From: Ed Maste <emaste@freebsd.org>
Date: Tue, 2 Aug 2016 04:19:36 +0000
X-Google-Sender-Auth: Bkp3feH-NQR-KWCcJ2aveymgnIQ
Message-ID: <CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5+-pWX+_V5ztzQ@mail.gmail.com>
Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system
To: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 04:19:57 -0000
For some reason Warner's email didn't make it to me, but I spotted it
in the list archive.
Warner writes:
> On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste <emaste at freebsd.org> wrote:
>> -N/--omagic, used by some boot loader components. We can achieve the
>> same effect with a linker script.
>
> Agreed. Or objcopy even.
I'm not sure objcopy (alone) can do what we need, because -N also
turns off page alignment for .data. But either way I don't think will
be hard to work around.
>> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
>> on the same architectures that use Clang (amd64, arm, arm64, i386). I
>> don't think there's a need for a WITH_LLD src.conf knob, but will add
>> one if desired.
>
> I'm on the fence here. Since it is ld.lld, I'm not sure there's much value
> here so long as it falls under one of the clang WITH/WITHOUT symbols.
Yeah, I planned to bundle it with some knob that already controls
lld's dependencies.
>> 4. Modify the boot loader and kernel builds to avoid using features
>> not implemented by lld.
>
> This can be done in parallel starting now. I may take a stab at the boot
> loader bits since I think that will be easy.
Sounds good. We want to have it done by that point in the list but
you're absolutely right that we don't need to wait to start working on
it. If it hasn't happened by the time we finish up the earlier tasks
I'll look at it then.
>> 6. Request ports exp-runs and issue a call for testing with 3rd party
>> software. Fix issues found during this process.
>
> Experience suggests this may be the long poll :)
Indeed, and that's a big part of my motivation for trying to make lld
more readily available as early as possible, even if we're still
waiting on some required features.
>> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
>> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
>
> For the WITH/WITHOUT things, this is just a matter of changing the default
> MK_foo setting, right?
Right.
> OK. How does this square up against the gcc 4.2 removal timelines and
> plans? Once gcc is gone, we'll have to use an external toolchain anyway
> to build mips at least (though clang is close, it isn't there yet despite Sean
> Bruno's wonderful work).
I'm intentionally trying to keep lld decoupled from GCC 4.2 removal,
and don't think it should directly enable (or prevent) any progress
there. I don't yet have a good handle on GCC 4.2 removal timelines but
will definitely pay attention to progress there and potential
interaction with lld work.
> What's the timeline for all this stuff, do you think?
Significant progress is being made in lld at the moment. I don't want
to speak for others who are doing much of the work upstream, but I
would not be surprised if within two months we can build a working
world and kernel with lld (modulo rescue and boot loader fixes). If
testing and ports exp-runs go well I'd guess we could make it the
default in head a couple of months after that.
> Generally, I like it though. My concerns are mostly with ports and gcc plans.
> Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan
> for both before we get out the axes. Note this is purely a timing argument,
> not whether to get them out, just when :)
Yes, fully agree. I want to have lld available as soon as is feasible,
but have no intention of trying to remove old GNU ld or GCC 4.2 until
a viable path forward exists for all architectures.
From owner-freebsd-toolchain@freebsd.org Tue Aug 2 04:30:22 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22657BACE95
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 2 Aug 2016 04:30:22 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com
[IPv6:2607:f8b0:4001:c06::234])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id DF718130C
for <freebsd-toolchain@freebsd.org>; Tue, 2 Aug 2016 04:30:21 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: by mail-io0-x234.google.com with SMTP id 38so202148721iol.0
for <freebsd-toolchain@freebsd.org>; Mon, 01 Aug 2016 21:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=4M+Hsmae1fapGBUUHByTwlpZpX4UQBRxTzXIf3uImKg=;
b=QxrNFkcvyGDicB8S5szOhgQTAgic/vVkFGjrbOkALFmMC3/8KyGeRy03kqr/M12liO
hRjnyAcWSDnG7zkuiFWRj8NZsARBNN9yRZpBiN4CtyopRsE/9Z6CMp3t5lK0BGznQeKm
VOgV4E9wrEDTA3vjRr9K2qtbcaxi2BRtv/ZAIzOOApZSupYdJs+sUYfiMvJMVDp6WSu3
olKNJS+GeVkiZ40tx9KFtN7u5orTaJzh0HScnEJ7yPOeZuYTE8dZRt1DCeBuXFvgCzZF
8tOicfzhCEO74WKiugiPIwsbNLEZepKkjtEmM5vZ4jStKgW3FmIbCXysevbgQprN16lo
jKZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=4M+Hsmae1fapGBUUHByTwlpZpX4UQBRxTzXIf3uImKg=;
b=Q38EGlvBO/W7cFbXoIsByPHfAb3vCkD2KHFfvHnyuoppr8cWC7mQqnDskyDxtFLq4s
g9I2e4z4KzndCAhFpq1SBZwhX1NifQ/+/kE43ksJm9AS5VESVB65ZDJ+lgz9H14nziCC
GPH+aaKNu/mfQ28Gw4nuTO92TRP8IllWHIOUEa7+e/J7mgClVn+LORhVEgCVdfMImErd
4wO71DobB4s2Bmdj/L/2m6wun0+atsYyoEloDcTL2uAQuRQFiDtHoSgeooP97XG6VPof
C117/d5xfG9/mFRrBxBRJiaUoeDxugA1G+jZNLc7N2xAGMKvLGgcBOQyPF2CXeqyLrdW
xE8Q==
X-Gm-Message-State: AEkooutgteVU1O+QGstREQuYloPD2c7WgyJrWkZ4FSGyqD6nAJFl7U2uYAtAM0uP3tCvfY4dCWfD7snLIPI+6Q==
X-Received: by 10.107.40.133 with SMTP id o127mr57334326ioo.183.1470112221069;
Mon, 01 Aug 2016 21:30:21 -0700 (PDT)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.79.137.131 with HTTP; Mon, 1 Aug 2016 21:30:20 -0700 (PDT)
X-Originating-IP: [69.53.245.200]
In-Reply-To: <CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5+-pWX+_V5ztzQ@mail.gmail.com>
References: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
<CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5+-pWX+_V5ztzQ@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 1 Aug 2016 22:30:20 -0600
X-Google-Sender-Auth: -AkhV8SlSV95Qhwcpc0bWIR-XnU
Message-ID: <CANCZdfqEYTBZV3JkW=KC7s5wquf3Q=aLnFU_6AbD_V5SxqHJiA@mail.gmail.com>
Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system
To: Ed Maste <emaste@freebsd.org>
Cc: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 04:30:22 -0000
>> Generally, I like it though. My concerns are mostly with ports and gcc plans.
>> Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan
>> for both before we get out the axes. Note this is purely a timing argument,
>> not whether to get them out, just when :)
>
> Yes, fully agree. I want to have lld available as soon as is feasible,
> but have no intention of trying to remove old GNU ld or GCC 4.2 until
> a viable path forward exists for all architectures.
Agreed. We don't have to have a plan for removal before moving forward
on lld.
Warner
From owner-freebsd-toolchain@freebsd.org Tue Aug 2 09:08:12 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id D441CBAC13D
for <freebsd-toolchain@mailman.ysv.freebsd.org>;
Tue, 2 Aug 2016 09:08:12 +0000 (UTC)
(envelope-from theraven@FreeBSD.org)
Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "cloud.theravensnest.org",
Issuer "StartCom Class 1 DV Server CA" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id B48021E60;
Tue, 2 Aug 2016 09:08:12 +0000 (UTC)
(envelope-from theraven@FreeBSD.org)
Received: from [192.168.0.7]
(cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150])
(authenticated bits=0)
by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u72982m4030647
(version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 2 Aug 2016 09:08:04 GMT (envelope-from theraven@FreeBSD.org)
X-Authentication-Warning: theravensnest.org: Host
cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to
be [192.168.0.7]
Content-Type: multipart/signed;
boundary="Apple-Mail=_A7BD7C79-9578-4E32-9A70-F1910698DF7D";
protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system
From: David Chisnall <theraven@FreeBSD.org>
In-Reply-To: <CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5+-pWX+_V5ztzQ@mail.gmail.com>
Date: Tue, 2 Aug 2016 10:08:04 +0100
Cc: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org>
Message-Id: <D7DFE5C9-2A34-479D-B5E3-170AD087F7F4@FreeBSD.org>
References: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
<CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5+-pWX+_V5ztzQ@mail.gmail.com>
To: Ed Maste <emaste@freebsd.org>
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-toolchain@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Maintenance of FreeBSD's integrated toolchain
<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>,
<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 09:08:12 -0000
--Apple-Mail=_A7BD7C79-9578-4E32-9A70-F1910698DF7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 2 Aug 2016, at 05:19, Ed Maste <emaste@freebsd.org> wrote:
>=20
>>> 6. Request ports exp-runs and issue a call for testing with 3rd =
party
>>> software. Fix issues found during this process.
>>=20
>> Experience suggests this may be the long poll :)
>=20
> Indeed, and that's a big part of my motivation for trying to make lld
> more readily available as early as possible, even if we're still
> waiting on some required features.
I believe that all of the base system clang=E2=80=99s for supported =
branches support -fuse-ld=3Dlld (perhaps 10.0 didn=E2=80=99t?), so if we =
have an lld candidate in ports then it should be easy for user to test =
it by doing a pkg ins lld and setting LDFLAGS. Failing that, the =
fallback to just replacing /usr/bin/ld with a symlink to =
/usr/local/bin/ld.lld would probably work for ports testing.
We=E2=80=99re probably going to want a =E2=80=98needs bfd / gold instead =
of lld=E2=80=99 knob for a while. We might need to patch the gcc =
versions in ports to accept -fuse-ld=3Dlld[1].
I suspect the longer tail for LTO. There is a bunch of low-hanging =
fruit in the FreeBSD tree where LTO would likely be a win (I=E2=80=99d =
expect most of the statically linked stuff to get smaller, if nothing =
else).
David
[1] gcc and clang interpret -fuse-ld differently. In clang, =
-fuse-ld=3D{foo} means =E2=80=98${PATH}/ld.{foo}=E2=80=99 is the linker =
and you should error out if it doesn=E2=80=99t exist. gcc instead hard =
codes bfd and gold as the two valid options and rejects anything else.=
--Apple-Mail=_A7BD7C79-9578-4E32-9A70-F1910698DF7D
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCCBPww
ggPkoAMCAQICECJrrb9nBol9MHok/UZg/AYwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx
FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTAeFw0xNjA0MTkw
OTI3NDJaFw0xNzA0MTkwOTI3NDJaMEQxHTAbBgNVBAMMFHRoZXJhdmVuQGZyZWVic2Qub3JnMSMw
IQYJKoZIhvcNAQkBFhR0aGVyYXZlbkBmcmVlYnNkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBALsL5pEhrGjrswHVdMHWhgxb8ARKDYRePSqpDLmjJ40bpx+n1zrvIwjC2Vk2IpoD
04rg5Pog2IrhnX+Qk2NSXzBXWj2JAaTc9OtSeAY0BtgJYXONGONQbRKVy97QBdzd1SbMEzDrOgH5
UDI+5sF1PboOTmLyTAPI9273XdfZ0BnstUXs8NXr/7p9E5CWJOsO1iQcINbm4XiwC1PLNMeWUknE
Nji/hFKwcE8IFtaUe1ymbw6yA3rBpDu3KewIRD1T66FPTZJeIzvUoBIqWd+GAOfCBG2QYmbc3y/x
K2hCtcXThcB1uVFA2q39koLKA8wHyqv4Jhm3wzhAqKDsWK4bGW0CAwEAAaOCAbcwggGzMA4GA1Ud
DwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADAdBgNV
HQ4EFgQU5J3Kc8GeW8pEGxBkcMoA7eUOPRwwHwYDVR0jBBgwFoAUJIFsOWG+SQ+PtxtGK8kotSdI
bWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20w
OQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGllbnQxLmNy
dDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xpZW50MS5j
cmwwHwYDVR0RBBgwFoEUdGhlcmF2ZW5AZnJlZWJzZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgUwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQBSBDH+kZf5
bZkNFcMSPdfnGC7F8utBIxs2bi3JQjsBoQTm1vnXdwgINSfO9At6iQZHoEyj8ZE6PcMFuEU0+bk0
aE8aYcW59WnxfWx943upZoMhX0YVaJcFK01EHFrddRAP44sh7Eu6JtdFuAG+6btDReMcg35Qm65X
7/280aVm7awadJ+IQs8r9qBVk2NFqkvHCETtJjNWXd7M6mcsfXstvykbubPQH/VNW/zrX6yzIcI4
aoz+Sn8RJmHNkk6cImqe1KvsdDLXmqCoeoMwos62pT18RaI//jwTdmnf5EHFMlevnxOr7rzA++71
OSZfdYf6+nvHOod1F721rNuy6lxFMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkq
hkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tfrh4bdcC1
Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR+8eklf/EqeZW
RLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I7062uHsskM8b7gPxmcC
oO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo12SLBO5tbk8h2imbKTC8i
Ms+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aMsvi2raFhC643SOGvErWWPPnS
EfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9j
cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5j
b20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAW
gBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGL
hK0PAQJbnOEjJyMEvTTwcAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm
7NKezWVnCHuwb3ptgFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAI
hV4L8aaya1u4s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1st
p+C7omqM5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8
wBUaBxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ
wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe3X+r
n0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvSodfiar0w
iM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqmRHYj1TjMSw0l
Al7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK7zmjozGCA04wggNK
AgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3Mg
MSBDbGllbnQgQ0ECECJrrb9nBol9MHok/UZg/AYwCQYFKw4DAhoFAKCCAZkwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODAyMDkwODA1WjAjBgkqhkiG9w0BCQQx
FgQUtsqZPgosC+jglGXnqVXhwwIjsf8wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJ
fTB6JP1GYPwGMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
IzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAia62/ZwaJfTB6JP1GYPwGMA0G
CSqGSIb3DQEBAQUABIIBAAqSOAo73xS9DY66iYkfexg3CMivr8g1DkJuBhBnyUwTu2DAzkkOZ9jH
GSWbXc1pimyaT/fsdPq1H4G1HkiTg9csD+74UFrx2DLDVClocYevdK+fXge34mZLkLGaTOI0gnVd
S0X08LXiit3UYUkk8Cmtrzi/3wn5mA3AeXalYERcPuTshl9JjqJDHCEI2IgCT0pO/Sv2ejt2acHg
KTfTkVMtPZxfDGjrInUZmRFIbiD2Mf/EWk2WgxAA86LMBC2RUos1j9z409ATFvG66Ard22ybCcEF
lwCBMrsXrAS0HQQKPSYzK4UpB6Lf+tgPdANsp735HhMj6mo+mf4sl5wMM74AAAAAAAA=
--Apple-Mail=_A7BD7C79-9578-4E32-9A70-F1910698DF7D--