From owner-freebsd-toolchain@freebsd.org Mon Aug 1 21:40:29 2016 Return-Path: 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 ; 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 ; 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 ; 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 Date: Mon, 1 Aug 2016 17:40:07 -0400 X-Google-Sender-Auth: op7nd7ahyYIsdlOfGRorcQT_9X8 Message-ID: Subject: Update on using LLVM's lld linker in the FreeBSD base system To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 ; 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 ; 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: References: From: Warner Losh Date: Mon, 1 Aug 2016 16:27:18 -0600 X-Google-Sender-Auth: sUBsNtZY-EXrvG_5SKoh2j1f2hI Message-ID: Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system To: Ed Maste Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:27:19 -0000 On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste 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: 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 ; 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 ; 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 ; Mon, 1 Aug 2016 17:05:54 -0700 (PDT) From: Mark Millard 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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: 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 ; 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 ; 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 ; 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: References: From: Ed Maste Date: Tue, 2 Aug 2016 04:19:36 +0000 X-Google-Sender-Auth: Bkp3feH-NQR-KWCcJ2aveymgnIQ Message-ID: Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: 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 ; 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 ; 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 ; 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: References: From: Warner Losh Date: Mon, 1 Aug 2016 22:30:20 -0600 X-Google-Sender-Auth: -AkhV8SlSV95Qhwcpc0bWIR-XnU Message-ID: Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system To: Ed Maste Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 ; 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 In-Reply-To: Date: Tue, 2 Aug 2016 10:08:04 +0100 Cc: "freebsd-toolchain@freebsd.org" Message-Id: References: To: Ed Maste 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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--