From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id E9CCE385084F for ; Thu, 20 Oct 2022 14:42:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9CCE385084F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 315861FB3B; Thu, 20 Oct 2022 14:42:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666276945; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=bEfabtJVSSmFTlVByEhZUpKTpCqxixCpNsn2VO3dWvo=; b=bdsdcStl0eeNYW7GUlGTOMABQV7AcSz8M0ZGa2R0XnVvf3k7i9MrJP0uwI1/zWejmkC2UW XAMH3+lrHGCaRUQfsctVTFy8re6gJy7MbAlz2CPW1VglJkq0d5CK3V1YEh2pHpaiaN3Sjk IZHoetZNrbarWTAIYP6Tg0qLBs8KkCc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666276945; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=bEfabtJVSSmFTlVByEhZUpKTpCqxixCpNsn2VO3dWvo=; b=Ipx1jY2wd5V0xhp9NPECJWyZQUBl4GU0Wb9Bazx5+L6NU37KQaIbwZXysklgEXnMSK+lSN qxAqCmkEcVpR9oAg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 2BB1C2C141; Thu, 20 Oct 2022 14:42:25 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 21A826457; Thu, 20 Oct 2022 14:42:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 20739644C; Thu, 20 Oct 2022 14:42:25 +0000 (UTC) Date: Thu, 20 Oct 2022 14:42:25 +0000 (UTC) From: Michael Matz To: binutils@sourceware.org cc: Alan Modra , "H.J. Lu" Subject: x86-64: Use only one default max-page-size Message-ID: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,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 List-Id: On x86-64 the default ELF_MAXPAGESIZE depends on a configure option (--disable-separate-code). Since 9833b775 ("PR28824, relro security issues") we use max-page-size for relro alignment (with a short interval, from 31b4d3a ("PR28824, relro security issues, x86 keep COMMONPAGESIZE relro") to its revert a1faa5ea, where x86-64 used COMMONPAGESIZE as relro alignment target). But that means that a linker configured with --disable-separate-code behaves different from one configured with --enable-separate-code (the default), _even if using "-z {no,}separate-code" option to use the non-configured behaviour_ . In particular it means that when configuring with --disable-separate-code the linker will produce binaries aligned to 2MB pages on disk, and hence generate 2MB executables for a hello world (and even 6MB when linked with "-z separate-code"). Generally we can't have constants that ultimately land in static variables be depending on configure options if those only influence behaviour that is overridable by command line options. So, do away with that, make the default MAXPAGESIZE be 4k (as is default for most x86-64 configs anyway, as most people won't configure with --disable-separate-code). If people need more they can use the "-z max-page-size" (with would have been required right now for a default configure binutils). bfd/ * elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on DEFAULT_LD_Z_SEPARATE_CODE. --- I was worried about this case already earlier the year (https://sourceware.org/pipermail/binutils/2022-February/119766.html), but at that time I didn't realize that not only an explicit request via -z max-page-size generates large binaries, but also just configuring binutils different would do so. For compatibility with old code streams I do have to configure binutils in such way and obviously we can't have that produce 2MB or 6MB binaries. --- bfd/elf64-x86-64.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c index f3b54400013..2ae8dffba0f 100644 --- a/bfd/elf64-x86-64.c +++ b/bfd/elf64-x86-64.c @@ -5259,11 +5259,7 @@ elf_x86_64_special_sections[]= #define ELF_ARCH bfd_arch_i386 #define ELF_TARGET_ID X86_64_ELF_DATA #define ELF_MACHINE_CODE EM_X86_64 -#if DEFAULT_LD_Z_SEPARATE_CODE -# define ELF_MAXPAGESIZE 0x1000 -#else -# define ELF_MAXPAGESIZE 0x200000 -#endif +#define ELF_MAXPAGESIZE 0x1000 #define ELF_COMMONPAGESIZE 0x1000 #define elf_backend_can_gc_sections 1 -- 2.37.3