From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95782 invoked by alias); 8 Jun 2017 21:07:31 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 95765 invoked by uid 89); 8 Jun 2017 21:07:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=proposals, crossed X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail.zytor.com Received: from terminus.zytor.com (HELO mail.zytor.com) (65.50.211.136) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Jun 2017 21:07:29 +0000 Received: from carbon-x1.hos.anvin.org (c-24-5-245-234.hsd1.ca.comcast.net [24.5.245.234] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id v58L3ADn030674 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 8 Jun 2017 14:03:10 -0700 Subject: Re: gABI extension proposal: PT_SHMMAP To: hegdesmailbox@gmail.com, Cary Coutant , James Y Knight Cc: gnu-gabi@sourceware.org References: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> From: "H. Peter Anvin" Message-ID: <491ac00d-e12b-746a-7b31-27726d659d8e@zytor.com> Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SW-Source: 2017-q2/txt/msg00027.txt.bz2 On 06/08/17 09:19, Suprateeka R Hegde wrote: > On 07-Jun-2017 10:40 PM, H. Peter Anvin wrote: >> Any particular reason that you feel this is not generally useful? > > 1. The use case provided looks extremely specific to Linux. AFAIK, none > of the unix like HP-UX, Solaris or AIX need this requirement. > > 2. This looks so specific to a runtime loader that it can be as well > handled as a special case in GNU mmap system (may be in ld.so). > > 3. Assuming Cary is right in understanding that you want a writable but > still sharable page, such features are not even provided by some of the > legacy unix kernels. > > 4. Eventually there can be many such flags if we start going with > specific claims. For instance there was a request for > PF_NOREAD/SHF_NOREAD that would help some archs (STM?) to protect code > from being read. > SHF_NOREAD makes total sense - there is no real reason for the current asymmetry between the SHF and the PF flags -- you don't need PF_NOREAD because you already have PF_R, but there is no SHF_ flag to indicate that a the resulting segment should be linked to be !PF_R. My proposal is also missing that aspect (see below.) > 5. Why dont we try to fit this proposal under the bigger one - program > properties - proposed by H.J. ? The theme there is to pass such > information to runtime. I think this is completely orthogonal - that would be a program property rather than a per-segment property? > 6. Lastly, the proposal looks incomplete: > 5-a. The hex value for the proposed flag is missing > 5-b. The proposal should be sent to Generic SYS-V ABI group and not > GNU-GABI alone. That is certainly true, but H.J. suggested vetting it here first, exactly to get the t's crossed and the i's dotted first. The PT_ vs PF_ question was one. > 5-c. The complete semantics of this flag in a standard form. The > semantics should talk about what is mandatory, what is optional. Is the > current/existing UNIX should be changed to honor this flag or is this > optional? So, a slightly refined proposal (if these numbers conflict with newer allocations/proposals please let me know): 0x00000008 (2^3) - PF_SHARED This segment MUST be memory-mapped using MAP_SHARED. Not all operating systems need to support this capability. If this is not possible due to lack of operating system support or because the underlying image is not possible to memory-map, the loading of the image should be aborted with an error. 0x00001000 (2^12) - SHF_SHARED This section MUST be made part of a PF_SHARED segment when linked. OPTIONALLY, new reserved section names: .shrodata - readonly data section to be mapped shared .shdata - writable data section to be mapped shared .shbss - zerofill section to be mapped shared