From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45044 invoked by alias); 9 Jun 2017 13:14:00 -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 43256 invoked by uid 89); 9 Jun 2017 13:13:59 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.192.194, H*RU:209.85.192.194, vendors X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS 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-pf0-f194.google.com Received: from mail-pf0-f194.google.com (HELO mail-pf0-f194.google.com) (209.85.192.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 13:13:57 +0000 Received: by mail-pf0-f194.google.com with SMTP id u26so8566296pfd.2 for ; Fri, 09 Jun 2017 06:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NFUhhQmmW0AG6505s+sWVP/VX9v+6pbF5q3xtXMpoQs=; b=ttUzu5v4BowD4fPnu/Qs3ExrsqhCGJNpKgt2SXT6S5tUc6XGo/ueASDWJsBR3v693S aUaZdvVswKACDPSbFshM4KaWczlS4CjLUx0XMvJRuFIxmSbLMoCYwT9XegMfnhbzyDFy 60BEhZqUHcKKdfltrHelk1coLNwJHo61FXk/fEKyezu0T9zYRTvfzjf9FlBzChaROuZ2 ycUwrnjCK9pEBEHVavdMY1+gDTN0pxol5BD11hLvyZzeun788UsjHGFtA3WCZBckUy4S NK87p/skfpgJGSwVl7PasRwDerlOTBoOSctx7X9ESXWVD5HDejbG63ddyDWsVStxm+vS Fr1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NFUhhQmmW0AG6505s+sWVP/VX9v+6pbF5q3xtXMpoQs=; b=PSDdMgP4gueAuqtrEQOdsWa+YJc0MSC/SPdovSN72lvs+AIiFpAQ9iusurrrugYdz/ EJv3vatS9MpUtfp9IJgCjgCrRAsUW0FKuW52PyivmZdBltIT8ggLdmqJVGpjld76qEFC CBHKOySJPY9ejJSCq7j2MaoHVI8+GRK5dUVZGKJ0ltFZYasrpWQu8dsmPYhY2dqVInSx NeiOgYlh6wGF+0/Fyd46Q3jCtFpK7ZTBPyXCD8jtUPuyipF1rLK4JqIhWCAk4q3DShBW BmI2Z/QMQqAnZgMiRkPR8yqeF1T+jY16DftqmHVpgxke8yYSXxuG+8uv4/1Xwxjacby5 yzhA== X-Gm-Message-State: AODbwcDrneLnX9nbJqxGlQ19E5yT2Eh9VqL8cdev2Z9r0AAQPktvgjvy gpy5SUmS0JzlL6miKlY= X-Received: by 10.84.178.129 with SMTP id z1mr40387754plb.171.1497014040249; Fri, 09 Jun 2017 06:14:00 -0700 (PDT) Received: from [192.168.1.2] ([103.16.201.114]) by smtp.gmail.com with ESMTPSA id s10sm3270482pfi.16.2017.06.09.06.13.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 06:13:59 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: gABI extension proposal: PT_SHMMAP References: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> <491ac00d-e12b-746a-7b31-27726d659d8e@zytor.com> To: "H. Peter Anvin" , Cary Coutant , James Y Knight Cc: gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <491ac00d-e12b-746a-7b31-27726d659d8e@zytor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 170609-0, 09-06-2017), Outbound message X-Antivirus-Status: Clean X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00028.txt.bz2 On 09-Jun-2017 02:33 AM, H. Peter Anvin wrote: > > SHF_NOREAD makes total sense Yes but under processor specific extensions. Not generally. >> 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? H.J's design, as far as I remember, was extensible to accommodate such handshakes between linker and loader. I may be wrong though. > 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. This is the reason I said it should be OS specific. The above definition itself is so attached to OS support. It would make sense to make it part of a generic standard when: 1. There are different loaders provided by different vendors for the same OS 2. (Hypothetically) A loader on one OS is expected to handle/load an ELF produced by a linker from another OS. > 0x00001000 (2^12) - SHF_SHARED > > This section MUST be made part of a PF_SHARED segment when > linked. This again is not complete. A non-ambiguous standard should also tell is it necessary for a gABI compliant ELF linker to mark sections that go into shared segments, as SHF_SHARED? Similarly, is it necessary for a gABI compliant linker to mark PT_LOAD that gets shared, as PF_SHARED? > 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 IMHO, these are so trivial that it is only worth to be done under a tool chain specific option. These are not at all useful in general. That said, 1. Send the proposal to Generic SYS-V ABI group. Lets see the consensus. 2. I may have to object this if the standards mandates that a gABI compliant linker *MUST* mark PF_SHARED to mean PT_LOAD as sharable. I am absolutely fine if marking PF_SHARED is optional -- I will not do it on HP-UX. -- Supra