From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 028E81A1DFE for ; Thu, 4 Aug 2016 12:18:13 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 38so280063530iol.0 for ; Thu, 04 Aug 2016 12:18:12 -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:content-transfer-encoding; bh=aZQYnBk8UnVos9pdqT5QXuR8Kw3qOi+fFyFXpes8ygw=; b=IibVHYItay34TxX+URYaLnbZcRglwNIK0xNFlehuTWeUXpw7/XeK8lWW4a2hQAZ1/a p/PCR/Ob4WvPQI09OyBt1bq3d80Geb/Xz5dUaRe0xDQxqnVy/1lsSnaB7ThbsG0f9dx1 6GzIEEBwzw5gPzeGIP/D/XJyCLgnmP4FKA2OI= 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:content-transfer-encoding; bh=aZQYnBk8UnVos9pdqT5QXuR8Kw3qOi+fFyFXpes8ygw=; b=OcGKtE3AsQaR2P7AA3397vyjArE1UN1L21WogBhDXw1g5uA+oy15HliyfbDVgdT48Y XEepuWEf/NM47pvjtkqO3UghxaCelOEVX8mHUkyF9M+YoOqC5we7X7HUFDc+FvWWHaZ1 09kc6cIRrPFiFoIM2Yeod07FhTHQLcS7xmntIeY3XWWKX/mEFnY1+pZhQMZVrJiIs0iH uYgl7oaY36JmBljEbPA3lQRKA59/3T61MQcVTR3vUnLNBJHesWtiI4T0ZKLRi49B+J1v 7evokFQkNdjgYehi5bu0b0NrtJBB01mwhtfJw8iLUAuvhfxT3Lj9yCMv+dHyYLc+lWQo uqJQ== X-Gm-Message-State: AEkoouum2By3It3b49aC/Cxf9+8+kzsOU4XVjEfb0UXQ2w+UPfSkIsqaQKmpzVBGNSmd2AT56unxFU17MRy+7zDu X-Received: by 10.107.135.22 with SMTP id j22mr85886987iod.56.1470338287751; Thu, 04 Aug 2016 12:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 4 Aug 2016 12:18:07 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Thu, 4 Aug 2016 21:18:07 +0200 Message-ID: To: "Cohen, Eugene" Cc: Leif Lindholm , "edk2-devel@lists.01.org" Subject: Re: Managing GCC Assembly Code Size (AArch64) 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: Thu, 04 Aug 2016 19:18:13 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 August 2016 at 20:08, Cohen, Eugene wrote: > Ard and Leif, > > I've been too backlogged to provide a real patchset at this point but wan= ted to get your approval on this proposal... > > > As you know we have some code size sensitive uncompressed XIP stuff going= on. For C code we get dead code stripping thanks to the "-ffunction-secti= ons" switch which places each function in its own section so the linker can= strip unreferenced sections. > > For assembly there is not a solution that's as easy. For RVCT we handled= this with an assembler macro that combined the procedure label definition,= export of global symbols and placement of the procedure in its own section= . For GCC I haven't found a way to fully do this because we rely on the C = preprocessor for assembly which means you cannot expand to multi-line macro= s. (The label and assembler directives require their own lines but the pre= processor collapses stuff onto one line because in the C language newlines = don't matter.) > > So the solution I've settled on is to do this: > > in MdePkg\Include\AArch64\ProcessorBind.h define: > > /// Macro to place a function in its own section for dead code eliminat= ion > /// This must be placed directly before the corresponding code since th= e > /// .section directive applies to the code that follows it. > #define GCC_ASM_EXPORT_SECTION(func__) \ > .global _CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\ > .section .text._CONCATENATE (__USER_LABEL_PREFIX__, func__) = ;\ > .type ASM_PFX(func__), %function; \ > > This has the effect of placing the function in a section called .text. so the linker can do its dead code stripping stuff. It also absorbs = the making the symbol globally visible so the corresponding GCC_ASM_EXPORT = statement can be removed. > > then for every single assembly procedure change from this: > > [top of file] > GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA) > > [lower down] > ASM_PFX(ArmInvalidateDataCacheEntryByMVA): > dc ivac, x0 // Invalidate single data cache line > ret > > to this: > > GCC_ASM_EXPORT_SECTION(ArmInvalidateDataCacheEntryByMVA) > ASM_PFX(ArmInvalidateDataCacheEntryByMVA): > dc ivac, x0 // Invalidate single data cache line > ret > > Because the assembly label must appear in column 1 I couldn't find a way = to use the C preprocessor to absorb it so hence the two lines. If you can = find a way to improve on this it would be great. > What about GAS macros (.macro / .endm). I prefer those over cpp macros in assembler anyway. > I'm not sure what impacts this might have to other toolchains - can this = be translated to CLANG and ARM Compiler? > The asm dialect is 99% aligned between CLANG and GNU as, so this shouldn't be a problem > I'd like to get your OK on this conceptually and then I could upstream so= me patches that modify the AArch64 *.S files to use this approach. Unfortu= nately it won't be complete because I only updated the libraries that we us= e. My hope is that long term all assembly (or at least assembly in librari= es) adopt this approach so we are positioned for maximum dead code strippin= g. > I think this would be an improvement, so go for it. The only thing to be wary of is routines that fall through into the subsequent one. Those need to remain in the same section.