Received: by 2002:ab2:2994:0:b0:1ef:ca3e:3cd5 with SMTP id n20csp676075lqb; Fri, 15 Mar 2024 03:24:01 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCV3cYOHvNRxPLtQDpLF8dv4ax1FlPbcfD4nP48oubJfYnVx1mPQEfQtCamlYuLnBcvI1v4GDtUCilcWRghiWp9Wb0Fw8SKAyBqcOQNaPg== X-Google-Smtp-Source: AGHT+IHRe2toAvGMdBiTmNHHID0lZJ1WhmqxfhIHwBjWIaxAdyiXWGVHV26tK4ni4XwQDDrSTbw5 X-Received: by 2002:a17:906:2c08:b0:a41:3e39:b918 with SMTP id e8-20020a1709062c0800b00a413e39b918mr1627932ejh.24.1710498241477; Fri, 15 Mar 2024 03:24:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710498241; cv=pass; d=google.com; s=arc-20160816; b=IbfYnAv6CruWHx1rqj87kShmbRMQj/cQ+BrcGBJRH5wBz/krI2xnYq4JykR0A5QDRT om1ZrgXVL2oLy7yfvGRInbhy+ASZ6qIPPHOQqg2HIyQ+v3sW0s168paHHTwgjFBNLLtl p2MFtMzFLUW17EY0R4ZHv/3g+h9j9C9ZeDO8A3uLr9QGB9sxyH24SbhuL7YMVrNHrSzg Oo8JV/asQ/dd+T2W1aRi757j+VI5PKgri1FGFh++y2vhfXI2orFvdUuBpyrZAxu2pyJI fMf+iwUGHNu7Jz5x8vV5nvrFQSNOwKXE9XiHDGFGKXPdSW7hi0zTY7g4M9D1z9jVjiz0 s2Wg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=2TgKZ1cM2Tai9qu//zMyD2ueNZO1G1kXs6mCnC3OYA4=; fh=PBlxtFWX8j61k4YTtyc1MJz5pNJIOQmMaTR6B3h23YI=; b=Y5LeUU9UhWBHxjE8Y06qa2U2uZIbbJscQV5GH9D5/LSwAhb79UMDRu2UaIwnyZH+nZ k6Igwyg2W2l8BlxFGkrve4BhASbg2yrqQMDwfEalhwZr3Y7v+CcvzHKKnF4BEBWsox/H 8CG4XWi2YSIT4NjjdRA0jQSzBNLiIOlcoNZvIxrU5RIe5/6fiytgwakOn6BV0Wy9N62a 5x/4qfHTCSjkyrjwK9hc5EeBzxBTFHE464Z26Xr19NkIY7MSDp7fxphwu6tluBKvbQS3 sbmAhun+hX1qXnBZpIri5smAayMzQsy/ohQsIbPsdZPd0PskLlfdj9p/qG16kuZanUQZ wTjA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-104254-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-104254-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id d3-20020a1709064c4300b00a3f14a99dacsi1666542ejw.322.2024.03.15.03.24.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 03:24:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-104254-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-104254-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-104254-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 0B1DB1F2252C for ; Fri, 15 Mar 2024 10:24:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3F43F1863C; Fri, 15 Mar 2024 10:23:55 +0000 (UTC) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2405317C60 for ; Fri, 15 Mar 2024 10:23:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.191 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710498234; cv=none; b=FyCD2LoGnNTLcj+Ooo/9lTsTe1Sx0CDAQOtZ7ZJYFM6m6mAPBwgd0ymOL6Ptpi60DE1zgVdEuOhDI1IvYw8r/T5dEO7r1BsIEspF+NH/RLOHn+bIKZRGxtsSGDQxmJoNLrWk6NK65kAxDChNvsmJ+MoU20EMLVVP0Ea10nanCFw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710498234; c=relaxed/simple; bh=vfHuvWzpTK5NOf8madoPPjwSObeXKLTo+T8TMTxCGgA=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Goic9zKJVdkp9FCNYmG8zyLZeLpF6SsY2D2+HUbaVh6+L65TJH8tTYMLf9URpjD2LeBlyiyFjMUlkO4FDA6LNQm9op1k4WmDm+13ylX/OTKOcussrOuUe51jOp6Umcn5IrROYS2zhoJgtDW8O+rukHfd1FYbmfomR1GYWKmSu5w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.191 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Tx0hL2S5jz1FMbw; Fri, 15 Mar 2024 18:23:30 +0800 (CST) Received: from dggpemd100004.china.huawei.com (unknown [7.185.36.20]) by mail.maildlp.com (Postfix) with ESMTPS id 2F4E8180061; Fri, 15 Mar 2024 18:23:48 +0800 (CST) Received: from [10.67.109.211] (10.67.109.211) by dggpemd100004.china.huawei.com (7.185.36.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Fri, 15 Mar 2024 18:23:47 +0800 Message-ID: Date: Fri, 15 Mar 2024 18:23:47 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH-next v3] arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Content-Language: en-US To: Ard Biesheuvel CC: , , , , , , , , , , , , , , References: <20240315063154.696633-1-liuyuntao12@huawei.com> From: "liuyuntao (F)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemd100004.china.huawei.com (7.185.36.20) On 2024/3/15 16:06, Ard Biesheuvel wrote: > On Fri, 15 Mar 2024 at 07:37, Yuntao Liu wrote: >> >> The current arm32 architecture does not yet support the >> HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in >> embedded scenarios, and enabling this feature would be beneficial for >> reducing the size of the kernel image. >> >> In order to make this work, we keep the necessary tables by annotating >> them with KEEP, also it requires further changes to linker script to KEEP >> some tables and wildcard compiler generated sections into the right place. >> When using ld.lld for linking, the KEEP keyword is not recognized within >> the OVERLAY command, Ard proposed a concise method to solve this problem. >> >> It boots normally with defconfig, vexpress_defconfig and tinyconfig. >> The size comparison of zImage is as follows: >> defconfig vexpress_defconfig tinyconfig >> 5137712 5138024 424192 no dce >> 5032560 4997824 298384 dce >> 2.0% 2.7% 29.7% shrink >> >> When using smaller config file, there is a significant reduction in the >> size of the zImage. >> >> We also tested this patch on a commercially available single-board >> computer, and the comparison is as follows: >> a15eb_config >> 2161384 no dce >> 2092240 dce >> 3.2% shrink >> >> The zImage size has been reduced by approximately 3.2%, which is 70KB on >> 2.1M. >> >> Signed-off-by: Yuntao Liu >> Tested-by: Arnd Bergmann >> Reviewed-by: Arnd Bergmann >> --- >> v3: >> - A better way to KEEP .vectors section for ld.lld linking. >> >> v2: >> - Support config XIP_KERNEL. >> - Support LLVM compilation. >> - https://lore.kernel.org/all/20240307151231.654025-1-liuyuntao12@huawei.com/ >> >> v1: https://lore.kernel.org/all/20240220081527.23408-1-liuyuntao12@huawei.com/ >> --- >> arch/arm/Kconfig | 1 + >> arch/arm/boot/compressed/vmlinux.lds.S | 6 +++++- >> arch/arm/include/asm/vmlinux.lds.h | 2 +- >> arch/arm/kernel/entry-armv.S | 3 +++ >> arch/arm/kernel/vmlinux-xip.lds.S | 4 ++-- >> arch/arm/kernel/vmlinux.lds.S | 6 +++--- >> 6 files changed, 15 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index b14aed3a17ab..45f25f6e7a62 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -114,6 +114,7 @@ config ARM >> select HAVE_KERNEL_XZ >> select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M >> select HAVE_KRETPROBES if HAVE_KPROBES >> + select HAVE_LD_DEAD_CODE_DATA_ELIMINATION >> select HAVE_MOD_ARCH_SPECIFIC >> select HAVE_NMI >> select HAVE_OPTPROBES if !THUMB2_KERNEL >> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S >> index 3fcb3e62dc56..affd30714f01 100644 >> --- a/arch/arm/boot/compressed/vmlinux.lds.S >> +++ b/arch/arm/boot/compressed/vmlinux.lds.S >> @@ -89,7 +89,11 @@ SECTIONS >> * The EFI stub always executes from RAM, and runs strictly before the >> * decompressor, so we can make an exception for its r/w data, and keep it >> */ >> +#ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION >> + *(.data.* .bss.*) >> +#else >> *(.data.efistub .bss.efistub) >> +#endif >> __pecoff_data_end = .; >> > > This is still not right. > > Can you just add -fno-data-sections to cflags-$(CONFIG_ARM) in > drivers/firmware/efi/libstub/Makefile? > I rebuild kernel in such way: --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -28,6 +28,7 @@ cflags-$(CONFIG_ARM) += -DEFI_HAVE_STRLEN -DEFI_HAVE_STRNLEN \ -DEFI_HAVE_MEMCHR -DEFI_HAVE_STRRCHR \ -DEFI_HAVE_STRCMP -fno-builtin -fpic \ $(call cc-option,-mno-single-pic-base) +cflags-$(CONFIG_ARM) += -fno-data-sections cflags-$(CONFIG_RISCV) += -fpic -DNO_ALTERNATIVE -mno-relax cflags-$(CONFIG_LOONGARCH) += -fpi but I am still encountering this error: arm-linux-gnueabi-ld: warning: orphan section `.data.efi_loglevel' from `drivers/firmware/efi/libstub/printk.stub.o' being placed in section `.data.efi_loglevel' arm-linux-gnueabi-ld: warning: orphan section `.data.screen_info_guid' from `drivers/firmware/efi/libstub/screen_info.stub.o' being placed in section `.data.screen_info_guid' arm-linux-gnueabi-ld: warning: orphan section `.data.cpu_state_guid' from `drivers/firmware/efi/libstub/arm32-stub.stub.o' being placed in section `.data.cpu_state_guid' arm-linux-gnueabi-ld: warning: orphan section `.data.efi_nokaslr' from `drivers/firmware/efi/libstub/efi-stub-helper.stub.o' being placed in section `.data.efi_nokaslr' arm-linux-gnueabi-ld: error: zImage file size is incorrect I am puzzled because I could not find any option named -fno-data-sections for GCC.