From patchwork Mon Jan 2 16:08:57 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 38142 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp4220960wrt; Mon, 2 Jan 2023 08:09:08 -0800 (PST) X-Google-Smtp-Source: AMrXdXuQzU/D1QWzRe0157RQek86J1I8ZTqJfVXrSJW6LydvyKC5KA0YbUwnjttNZoRX6Mq+Ac/y X-Received: by 2002:a17:907:d684:b0:7c1:11fd:9b98 with SMTP id wf4-20020a170907d68400b007c111fd9b98mr33965245ejc.27.1672675748651; Mon, 02 Jan 2023 08:09:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672675748; cv=none; d=google.com; s=arc-20160816; b=Zfl1ibdwDeBbZu3pwZDj5iEaMiil4S3ExDWoqvWqch343GpZiWnylF9VS7bptqNj/B Uoi/iUFt+rK+1w9gJHKHfJsy/ZB9v+MvlYzXwKvCoDyto69bpvQSjsIwqaU5athpbHLt q/aWgrezYts19Xps9UKoAthmNcWnYhbqEUuRTRsIqMh02oEpf9F1a6HxX5+Q99umquwB rF/L3PkVtOTkI+hz5ua6otXRblYbCjYm3PYuHbSnY6PVhrSZG0r9MyqkMc4GBO6ixtm5 NUcctcAWPXUwANDEq3+opIUjbQlfooPJAlvcWx+7HDNeETov1ka67VkpLUNdb9+HkXWM Uesw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:date:message-id :content-transfer-encoding:mime-version:subject:to:delivered-to :dkim-signature:dkim-filter; bh=2ZSvUWmh9W+yaa0HK/z0ms24UH1krqIwJEfeTnDVdLU=; b=avVZ2wIt/g1eEwVBts4XHP6fCpT/YxbcH3NqM4bCBaaQW+EW4IPhb7NFxOrU7aVLXQ qpSX3NtwrYWR7fgQ4OSKdVdD+aC+ToC1PBbWNBxIxeZsVJHdUODQp8w4f8OYUh9HHnSi UpwsCHl4Nm1VG/4yjjOd2iR6U1YxJAxmSFtsG1k00l3PiLlgDui26156CQgju2vv4Kyq pQzFyNTdfgP4srN8TgbJuGu+FT82KXpPSvvOsjmG3P8jKLt9fK+yW9NOLgC/yZPYLtEf +eOnsTfivJx+JKdjXUsekXmyYzatabECiY1MWm+PEUbORmWnaG7jfAiNqsSdAdwyP7tg 8f+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=qBv5nAVv; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id xg3-20020a170907320300b0078316f0b5f8si25644115ejb.88.2023.01.02.08.09.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jan 2023 08:09:08 -0800 (PST) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=qBv5nAVv; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 739C93858C2D for ; Mon, 2 Jan 2023 16:09:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 739C93858C2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1672675747; bh=2ZSvUWmh9W+yaa0HK/z0ms24UH1krqIwJEfeTnDVdLU=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=qBv5nAVvH7AnCtGr+EiYWsdqOAdmKloYxpkiYCd0u/cNUPQhIk9xg6DlKyB5FSdkm K5ZFQ3DuqAdwSdbwbLNn1FeCS6d3b8BmRpUto3KfFHnZ5rZTEPAqNtaEWSZE4nTLoV bB+JhBJzYI12JdqCFdSS3WBTBvDvknwfGGBfopwA= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id 1BC073858D32 for ; Mon, 2 Jan 2023 16:08:58 +0000 (GMT) To: Subject: [PATCH] Fix ld bloat introduced between binutils-2.38 and 2.39 MIME-Version: 1.0 Message-ID: <20230102160857.ABA7F2042C@pchp3.se.axis.com> Date: Mon, 2 Jan 2023 17:08:57 +0100 X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Hans-Peter Nilsson via Binutils From: Hans-Peter Nilsson Reply-To: Hans-Peter Nilsson Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753927645548090907?= X-GMAIL-MSGID: =?utf-8?q?1753927645548090907?= (Subject is for email list use, see below for a better commit title.) Ok to commit? If so, binutils-2.39 and 2.40 branches too? If not, suggestion of other approaches, no later than configure-time? --- 8< --- Subject: Let --with-elf-maxpagesize=N override target ELF_MAXPAGESIZE Since commit 9833b7757d24, "PR28824, relro security issues", ELF_MAXPAGESIZE matters much more, with regards to layout of the linked file. That commit fixed an actual bug, but also exposes a problem for targets were that value is too high. For example, for ARM(32, a.k.a. "Aarch32") specifically bfd_arch_arm, it's set to 64 KiB, making all Linux(/GNU) targets pay an extra amount of up to 60 KiB of bloat in DSO:s and executables. This matters when there are many such files, and where storage is expensive. It's *mostly* bloat when using a Linux kernel, as ARM(32) is a good example of an target where ELF_MAXPAGESIZE is set to an extreme value for an obscure corner-case. The ARM (32-bit) kernel has 4 KiB pages, has had that value forever, and can't be configured to any other value. The use-case is IIUC "Aarch32" emulation on an "Aarch64" (arm64) kernel, but not just that, but a setup where the Linux page-size is configured to something other than the *default* 4 KiB. Not sure there actually any such systems in use, again with both Aarch32 compatibility support and a non-4KiB pagesize, with all the warnings in the kernel config and requiring the "EXPERT" level set on. That may sound like an argument for setting the bfd_arch_arm ELF_MAXPAGESIZE to 4 KiB, but then the obscure corner-case wouldn't be properly handled. I wouldn't oppose that, but I prefer not to regress the linker by default in my own patch. I know about the linker option "-z max-page-size=0x1000", but that requires finding every linker invocation or patching gcc -and still finding all stray naked ld calls. There was for a short while config.relro_use_commonpagesize in the linker (commit 31b4d3a16f20) but besides the self-explanatory ld_config_type member, IMHO it's too obscure to re-introduce. Instead, I suggest simply making ELF_MAXPAGESIZE generally overridable by means of a --with option at linker configuration time. In the patch I make the option ELF-specific mostly for simplicity (more object-formats means more places to find and patch, also the original problem is ELF-specific). bfd: Let --with-elf-maxpagesize=N override target ELF_MAXPAGESIZE. * configure.ac: Define FORCED_ELF_MAXPAGESIZE if --with-elf-maxpagesize=N is passed. * elfxx-target.h: Let FORCED_ELF_MAXPAGESIZE] override ELF_MAXPAGESIZE. * configure, config.in: Regenerate. --- bfd/config.in | 3 +++ bfd/configure | 22 ++++++++++++++++++++-- bfd/configure.ac | 10 ++++++++++ bfd/elfxx-target.h | 5 +++++ 4 files changed, 38 insertions(+), 2 deletions(-) diff --git a/bfd/configure.ac b/bfd/configure.ac index 82a3d1f832e7..88eaa52b5a82 100644 --- a/bfd/configure.ac +++ b/bfd/configure.ac @@ -115,6 +115,16 @@ AC_ARG_WITH(mmap, *) AC_MSG_ERROR(bad value ${withval} for BFD with-mmap option) ;; esac],[want_mmap=false])dnl +ac_default_elf_maxpagesize=unset +AC_ARG_WITH(elf_maxpagesize, + AS_HELP_STRING([--with-elf-maxpagesize=N], + [Set ELF_MAXPAGESIZE to N instead of using the target value]), +[ac_default_elf_maxpagesize=$withval]) dnl +if test ${ac_default_elf_maxpagesize} != unset; then + AC_DEFINE_UNQUOTED(FORCED_ELF_MAXPAGESIZE, ${ac_default_elf_maxpagesize}, + [Define to a value with which to override the target ELF_MAXPAGESIZE.]) +fi + AC_ARG_ENABLE(secureplt, [ --enable-secureplt Default to creating read-only plt entries], [case "${enableval}" in diff --git a/bfd/elfxx-target.h b/bfd/elfxx-target.h index 9bcbdfb27dd8..2a32b8a8cb0d 100644 --- a/bfd/elfxx-target.h +++ b/bfd/elfxx-target.h @@ -374,6 +374,11 @@ #define ELF_OSABI ELFOSABI_NONE #endif +#ifdef FORCED_ELF_MAXPAGESIZE +#undef ELF_MAXPAGESIZE +#define ELF_MAXPAGESIZE FORCED_ELF_MAXPAGESIZE +#endif + #ifndef ELF_MAXPAGESIZE # error ELF_MAXPAGESIZE is not defined #define ELF_MAXPAGESIZE 1