From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 B6EFD1A1DFE for ; Thu, 4 Aug 2016 12:47:06 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id b62so280582829iod.3 for ; Thu, 04 Aug 2016 12:47:06 -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=PeehHR1Yz4R3jt4rQPYhNCM22EoPE15LaiiJo4T9KnM=; b=TvkqRAhGh7VJgE+XbF8q4JABNaHc0iWdzAJ+refvrhNOM0dmuxkAqtyoe+/eFGMkvG EkDwb/tYfE6A4n4ki3Y3iCJsXS9ii0tJ5Nwh6xrC6k3GvnmZ6zoVKyy6ByK/wibGWM0E mWH0kWzZBYuOL7eNsyobg5bF+dFt4bZzlFQEg= 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=PeehHR1Yz4R3jt4rQPYhNCM22EoPE15LaiiJo4T9KnM=; b=cEVjA5U3IKFdPcDXG/6O1I5eJ2uA+y4i74QaPjVcXpLk7Ekm+7u7YiiJAzaQ2lWKPk UDhYNVNHncgz1MFl/AQF+1W3lo44a8wr8WA0PZG+ys2zxD1qluDN6qU2jYQkEZAYwgzh XaO0ika8+TwWETijDZJxNJJpzjRhwtpbRsIW1u/eQIorbWDxpH2PmJCNNpmLlmouuPWn L17f74geAqFoYjKeMFY6+ZJO0r8BdkTHSxTXa78VwLvivB39qdNx8c9NVOhxikdxl6a5 Y7PkDUkpUGF06IzZkXp8j/zjeu69CixzWzHfPtDF8bkA5G1SSl0oc6wxy5DVRX0W1GZE p4qw== X-Gm-Message-State: AEkoouv8nP29MPjEh0/XDLWmiSkfifCAcdoVIn2cVjwlutYr4BPZpfzxEDm9a1XGdlt5ncCWR+cvkXbSWVKnQMA7 X-Received: by 10.107.40.133 with SMTP id o127mr72779253ioo.183.1470340026045; Thu, 04 Aug 2016 12:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 4 Aug 2016 12:47:05 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Thu, 4 Aug 2016 21:47:05 +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:47:06 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 August 2016 at 21:18, Ard Biesheuvel wrote= : > 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 wa= nted to get your approval on this proposal... >> >> >> As you know we have some code size sensitive uncompressed XIP stuff goin= g on. For C code we get dead code stripping thanks to the "-ffunction-sect= ions" switch which places each function in its own section so the linker ca= n strip unreferenced sections. >> >> For assembly there is not a solution that's as easy. For RVCT we handle= d this with an assembler macro that combined the procedure label definition= , export of global symbols and placement of the procedure in its own sectio= n. 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 macr= os. (The label and assembler directives require their own lines but the pr= eprocessor 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 elimina= tion >> /// This must be placed directly before the corresponding code since t= he >> /// .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. > FYI there is a null token \() for GAS which you can use to concatenate a string with a macro argument, e.g., .macro func, x .globl \x .type \x, %function .section .text.\x \x\(): .endm >> 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 s= ome patches that modify the AArch64 *.S files to use this approach. Unfort= unately it won't be complete because I only updated the libraries that we u= se. My hope is that long term all assembly (or at least assembly in librar= ies) adopt this approach so we are positioned for maximum dead code strippi= ng. >> > > 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.