From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 09E5C1A1DF3 for ; Mon, 8 Aug 2016 23:09:18 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q83so2942994iod.1 for ; Mon, 08 Aug 2016 23:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YDEsDVaO7ePDCj9OyPOi98yfVSUmZBgut5acv0eqlyI=; b=Lr2Z7bbUdr7dP6cU/uXJR85UH8mrZ/O0rquLBOebfHszKToIvP1OAN4iDiZOaK2COw d9tRxPoBUmEH3MVejpC3dNj/HV0eDwstf7qf1b67RAJxHE2lAKiyvuph4YlLZzxvZh75 LR6zr42jOhJVcdN7eRN2O102RZ3YbgC1G5ehY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YDEsDVaO7ePDCj9OyPOi98yfVSUmZBgut5acv0eqlyI=; b=iTwLgoTPnLTSK2idQ/GeShl3e+K2P6C727ETPnrVkYn4qipiByPX+Ws4Afg2/hCpz8 DE+pJU72vdtaFoQgEFSLBammsg7DLKDCDyVBjo0s96xFLX8RTXknc0GvejQ/hDM5hFQx q51bgU6dDRm+m1fW/fGWFHiSvVRTCVmFvkI2TH02C5xSRCqYJsJhyxqK1/Rm7j7HBVWg npIpoZe1UyxbwmQhodG6Plm1OJPaSTZ0Gpf+OLntgs8ByuEHPviFFvGRrntpIJBpDj6Y Cxx+e+kvMMqRx/2rRKkDNvCtEAuc9hpNLi3/XXSHjjB9zgLMd758ZU9k7+sbO9X0YFbN 3I6w== X-Gm-Message-State: AEkoouuKW5Pgf1vgcgiqNJ3VAP+44SxZCJLOvcFlPaAzP4Xby/kJehQ6c7iukPa3+yNKnaz8Ifx1UH1NIRVw+c9g X-Received: by 10.107.40.133 with SMTP id o127mr94294499ioo.183.1470722957296; Mon, 08 Aug 2016 23:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Mon, 8 Aug 2016 23:09:16 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Tue, 9 Aug 2016 08:09:16 +0200 Message-ID: To: Michael Zimmermann Cc: valerij zaporogeci , edk2-devel , Leif Lindholm Subject: Re: Toolchain question X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 06:09:18 -0000 Content-Type: text/plain; charset=UTF-8 On 9 August 2016 at 06:07, Michael Zimmermann wrote: > Hi, > > I assume that you are using linux because you're talking about ELF files. > MinGW may be able to compile PE images in Linux but tbh there's no reason > for that and the "freaking" translation is actually a pretty good > implementation and works very well. > Agreed. I suppose Microsoft may offer a toolchain that targets Windows RT (if that still exists) but free implementations like GCC and Clang are not likely to implement this any time soon, simply because, other than UEFI, there are no use cases. The ELF translation may be a bit clunky, but it is very effective, and allows us to use a wide range of toolchains: RVCT (ARM only), GCC and Clang, all of which are under constant development. > As for the kind of toolchain to use: there's always (at least) two types: > bare metal toolchains(arm-eabi,arm-none-eabi, aarch64-elf), and the ones > with a OS ABI(androideabi, linux-gnueabi,linux-gnueabihf, ...). While unlike > other bootloader/kernel projects EDK2 seems to work with all of them I can > only recommend using the bare metal variants. > I use both, and never notice any difference. The primary differences are newlib vs glibc, and in some cases, whether symbols are decorated with a leading _ The actual code generation is more dependent on the default target (i.e., -march/-mthumb for ARM) than bare-metal/hosted. > For ARM and AArch64 I recommend using linaro's latest stable release(5.3 at > the time of writing): > http://www.linaro.org/downloads/ > sometimes the website is out of date and you can go here directly: > https://releases.linaro.org/components/toolchain/binaries/ > > I've also CC'ed the Arm maintainers so you'll actually get answers unlike me > when I asked the same question about a year ago ;) > We have had good results enabling LTO for GCC5. However, we only recently added support for this, and Tianocore needs some tweaks that ordinary glibc based environments do not need to enable LTO. Please report any issues you see with GCC5, or switch to GCC49 (which works fine for GCC 5.x toolchains as well, but does not enable LTO) -- Ard.