From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 4B80A3858416 for ; Wed, 10 Apr 2024 11:57:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B80A3858416 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4B80A3858416 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712750278; cv=none; b=vTC0gOotiJorpJG6+MbYYXJqFzv/8ayepaTo/WiYQj/ENHJgnXf76j4D3kb09F17QO7wqlPnH5ZthEbU1IJJuxwGO0czfsLED8VEWP8tRD8cHdXdUG39mJHIdw3HON23pGsHjPlmCWg/A0wbF5/CrSg4gZatxmkL2rulYfD6bNQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712750278; c=relaxed/simple; bh=UeTixXfOI+sbzDs89QaWogN/0Qytt9rjB8SvSwAjQ08=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=jxmR4gd/GKL+loWHxrczFtcwvyE5ocOFJoufkBTQythbUK0F0YDhJUZ2a2l4iQn+VdzjU6267WpbzuTGjcDx3T47bkUEVY9+t59dOX/lKrNVhcVIDpY/9WyjwA5LpHZMmGQzAswmeNlrsYWePQWraAXWHRpJKKJ26agVqvf8jh4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712750276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rZl/O1cT7p/5FqdY1Vapflqvv6RfQjp4eeOZzEZgXOc=; b=jJFUZ1IainGgYVXULjfhWT6vzi18hxBE8BOuP9i+mR3AYoxNNA6Z6mJtA8gzaBfGgA5Qvz DHNv2+4zYNK7WU4dQjX8RPp3K8bTDV/xLd6+NSleMzAYqJ7aFHMmTDeTx1k6GYZmTIzVZg mNsr6EnwBAme70LBTg1xVWWLsA/U3VY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-395-ZSPt5tqoOGir5JvNGB_GRg-1; Wed, 10 Apr 2024 07:57:53 -0400 X-MC-Unique: ZSPt5tqoOGir5JvNGB_GRg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 33924104D50A; Wed, 10 Apr 2024 11:57:53 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 10DE3C0157E; Wed, 10 Apr 2024 11:57:51 +0000 (UTC) From: Florian Weimer To: Sergey Bugaev Cc: Samuel Thibault , libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE In-Reply-To: (Sergey Bugaev's message of "Mon, 25 Mar 2024 15:24:14 +0300") 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> Date: Wed, 10 Apr 2024 13:57:46 +0200 Message-ID: <878r1l2zwl.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: * 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. Thanks, Florian