From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 9C1881F44D for ; Mon, 15 Apr 2024 12:54:33 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=MFPN2BBr; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B5C723858CDB for ; Mon, 15 Apr 2024 12:54:31 +0000 (GMT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id AD8853858D39 for ; Mon, 15 Apr 2024 12:54:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD8853858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AD8853858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::235 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713185650; cv=none; b=buNhh0TYUtTQbzf0lcL3OMyI7TSN+wfuIPcW7lUHa/05jV7NfMm3GrXpucxfVFMysmsgKRlXfMrGUFWR0XsJUnUKqQtNTtIZXWTRep1TuH18pZC6IZ2LGrYBm7CZ+6QmXeNnS177qqSl0NSLFq2CgvJcOYEbvpqUmIlYXrGrriY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713185650; c=relaxed/simple; bh=Olxm6q0C66PKfwQV+68meLePK5mXlEXgv4yJ4D7gYLM=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Yhu3SKCUm4I+MZMGHV7/JJzxwAyUcoVqk3hGxNzrnT8hq86jNkyRT25gDqxk0Uhxy971IDJk5vz9uraaVY7EuQ/8BClHIjOBQppD8Oo4+8e6nD2ec9MWucmww6EqVnwk+hUT50bLpZgE9qLXEHPVD7Uoc9LChQgCJD9hfzXOSV0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3c70e46f3caso445137b6e.2 for ; Mon, 15 Apr 2024 05:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713185648; x=1713790448; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8pytcNvEt3nQJHoj86E6k/07+P8AUF45dlyOcBS0eJE=; b=MFPN2BBr23CwBYhQy4O3gauiM1pmQGMGcy2130B2+va6zL1JnoNl1gyV7nULZ1++4M /sVJJ+KxNh/w39KhjFZzkD4Mqipt8iXEZ/Ta6622cjU91k84CksKXNztlThM37J9h5a0 u4cYmBGZFp+8P1BK90JLDguILRFHES12EyDV8NLTU9dY1vD90BTE3d+q9GdC3jZtlLGj BMGhs35NBH5IzTKE3id/kpku03EcIGa/A8Qw+DXkDbFa7/XHx3xOt7zdM3c6gG2mwmdN Cx6lBcb3mpIaFUY39u9/ckS0dt6QvOXhjgo2eTo2/0VYewqP4SuhXyZMeAqcqGMs+E/y h66Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713185648; x=1713790448; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8pytcNvEt3nQJHoj86E6k/07+P8AUF45dlyOcBS0eJE=; b=HM7K9Dk22mGYLVeUdjrxtnOhlKkSJqRlAsEiqp/lj++skx0uZswXOlL5e3gV4V7+Zv D2FbMeMSUvDur+4+Ih+UMb0UaSjlD9Un2HagO/oKVilcNVaR2CfsBrptbIhaLR0KLRQe PqH1hsGyxJ+u/sDCMnM/52nwkwdoKCDUlL9Ag3W6HNfiqJ2IlIsoXhB8yrxGCKOdrfw1 bvipsv4Nl3vEMWly/9cWe5GbzptFJMn/fm81IYsm3yxDPQKqdIo80vdma3AQmXgCuk/i 22mw6Qlx0rQMQMd1xjCGZcn2tfBXoti5VpS6WYFMC1A3UnFe6GKy0dVBIiYdiu/wz1gB k1MA== X-Gm-Message-State: AOJu0YxZvy33+XA0xKPLKqHFNvQ5RMXW2b2XjTpFMqccNhqWFzID+i3G yTVTcgYW7hjaaUNIOoZFVp9htpGLlW7Vuviaj2okJ6Jz9xk2Iq4Rf3bG6UnEeNzARbav/CIMAWU F18t2ZRIlLjmT5aJWd0IKZRn5hAQ= X-Google-Smtp-Source: AGHT+IHTE3s75lr3nPMQRBeTABSAA8nBmf02Yam3sTtlA8td4V9R0PSqUQFPu2k0SuAq7BCAkSGWS11FOrS/MUQ1ejs= X-Received: by 2002:a05:6870:6107:b0:22f:8a05:1a6b with SMTP id s7-20020a056870610700b0022f8a051a6bmr11178184oae.29.1713185647932; Mon, 15 Apr 2024 05:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20240103171502.1358371-1-bugaevc@gmail.com> <20240103171502.1358371-4-bugaevc@gmail.com> <87y1aon3vc.fsf@oldenburg.str.redhat.com> <877chqa5gq.fsf@oldenburg.str.redhat.com> <878r1l2zwl.fsf@oldenburg.str.redhat.com> In-Reply-To: <878r1l2zwl.fsf@oldenburg.str.redhat.com> From: Sergey Bugaev Date: Mon, 15 Apr 2024 15:53:57 +0300 Message-ID: Subject: Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE To: Florian Weimer Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Hello, On Wed, Apr 10, 2024 at 2:57=E2=80=AFPM Florian Weimer = wrote: > * Sergey Bugaev: > > > We could define EXEC_PAGESIZE to some conservative value on > > aarch64-gnu too, if it turns out that this little workaround is really > > required. But it seems cleaner to make sure we don't need to, as > > Roland's email suggests, and introducing a new port that doesn't have > > a fixed page size (and doesn't come with an EXEC_PAGESIZE value > > already defined in kernel headers) seems to be a good opportunity to > > do that. That's my reasoning here. > > But the ELF image must be laid out with certain expectations regarding > the maximum support page size. Otherwise, something (kernel or dynamic > linker) needs to perform copies or upgrade conflicting permissions > within one page to a superset of all permissions. I don't think we have > code for that today, and we wouldn't necessarily want to implement that, > I think. Certainly -- and I wouldn't expect the kernel or the dynamic linker to do anything about it other than reporting an error. I think what you're saying is you consider EXEC_PAGESIZE to indeed describe/define this required alignment of ELF segments (as the name suggests). If I adopt that view, then yes, having EXEC_PAGESIZE makes sense, and it makes some sense to use it as a conservative page size value to use while the real value is not yet available (assuming there is a real need for that). The way I've been viewing it -- based on the fact that neither Linux's nor glibc's (dynamic) nor BFD's nor LLVM's (static) linkers use it for that purpose -- is that it's just some PAGE_SIZE-like definition that's unrelated to binary loading (despite its name -- perhaps it has been historically related to segment alignment in some old versions of Linux?) that has been co-opted by glibc for pre-initializing dl_pagesize, for dubious reasons. It also seems to be a Linux- (and x86 Hurd) specific thing; I cannot find it in the BSDs. Which one is it? Sergey