From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69764 invoked by alias); 7 Jun 2017 15:54:37 -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 68160 invoked by uid 89); 7 Jun 2017 15:54:36 -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=H*RU:!192.168.1.2!, Hx-spam-relays-external:!192.168.1.2!, Hx-languages-length:1812, H*r:ip*192.168.1.2 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-it0-f66.google.com Received: from mail-it0-f66.google.com (HELO mail-it0-f66.google.com) (209.85.214.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jun 2017 15:54:34 +0000 Received: by mail-it0-f66.google.com with SMTP id 67so1566473itx.2 for ; Wed, 07 Jun 2017 08:54:38 -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=eLlSCDfR0GgSdKfA+3kCExOifApBvRrGqUcbAlkqtfg=; b=IHJgG1aX6P8ETzl+tltmDuBXoAAPVZHzHPHnUiKaPHTvhFhtX2n4tOxHo+dAGw0PQQ fiN4MhlRKZBYC76KLoFEF5aO1U6rUuRqVhSycMKHCnbANgD487KSSQUVuq1oTGVM29LP MSh0YmeyBwwFOfQzykas1yhS7NbS9+eUzaphPBJLF4wAfnk1lf5uxN2eW9yJiL5fSW5D 7+l9CY+takrft2vHXZUMu328oXJm9XZTC1sRPunid76vNlyb8PpVyzRJgCYkssi9ZH2k LG4eaEUITm/zn58YASm9mJHYSZiXGjwCYBI80w2ABORsrMHTBFGTcx+5Om6+Rmcpaqb3 VvNw== 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=eLlSCDfR0GgSdKfA+3kCExOifApBvRrGqUcbAlkqtfg=; b=LaA8qFQjqYS0vpm6NY7m8CuTzKqhFLJj2gTUdW21VMKICAeDMDXDovXOrFwGc36s2E mwqXsrg4iXeZTcskMPQ/Tr4TjpMwsKASA2w8XVUUXBpLjUx3fdvYZLJMNtDBQmzr8vWm U9eLFp4F/fuM+sOsAXPYD+qmSc4lUp3w43RV4WVu3nNxH1fC1BYVjDPLSMbkXMc9p4q5 l54n9hzUPnHeVrAS4oN4hhD40ZNGkpQDDcsitiFZ0A9j0/73ccKWL64275FMX+30TR9k zc2c1FZMp++iiGKW3FQKPqciQg+Bimb9bER1SiQGzZon3j7bDH0a+tngNk16HQR0382v kMJw== X-Gm-Message-State: AODbwcDMs7X7BpN0XFF9m3uDY3MToAbnIE7PcLwkX6bA+H9RF8ECWSkJ XuR4awKiXdEcOxRgbkA= X-Received: by 10.36.242.6 with SMTP id j6mr440486ith.1.1496850876424; Wed, 07 Jun 2017 08:54:36 -0700 (PDT) Received: from [192.168.1.2] ([103.16.201.114]) by smtp.gmail.com with ESMTPSA id y79sm941490iod.13.2017.06.07.08.54.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 08:54:25 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: gABI extension proposal: PT_SHMMAP References: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> <6F367329-5B48-4702-B9F0-5637EF4A460D@zytor.com> To: hpa@zytor.com, Cary Coutant Cc: gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: <18d0b96e-57c3-7ba2-f533-6a8d1b4c6fd0@gmail.com> 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: <6F367329-5B48-4702-B9F0-5637EF4A460D@zytor.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 170607-0, 07-06-2017), Outbound message X-Antivirus-Status: Clean X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00020.txt.bz2 Please add it under PF_MASKOS range similar to other existing flags like PF_MIPS_*, PF_HP_*, etc. May be something like PF_GNU_SHARED. -- Supra On 02-Jun-2017 01:08 AM, hpa@zytor.com wrote: > On June 1, 2017 12:15:52 PM PDT, Cary Coutant wrote: >>> I would like to propose an extension to the ELF gABI, which is >> analogous >>> to PT_LOAD except that it requests that the underlying file be >>> memory-mapped with MAP_SHARED, rather than MAP_PRIVATE as used for >>> PT_LOAD. PT_SHARED or PT_SHLOAD would be other possible names. >>> >>> The main motivation for this is to allow the Linux kernel vDSO to >>> finally become as close to an "ordinary" ELF DSO as is possible. The >>> vDSO depends on having its kernel-provided data page(s) at a specific >>> offset from the vDSO code; this is currently done by ad hoc memory >>> areas, which has a number of problems, especially for mixed-mode >> programs. >>> >>> The idea is to convert the vdso to a proper file in one of the >>> kernel-provided filesystems (e.g. /proc or /sys); by defining this >> type, >>> an ELF parser would be able to create the appropriate mappings >> without >>> any ad hoc code. >>> >>> This may be usable for other operating systems or perhaps even in >>> userspace. However, if there is no such interest then it would be >>> possible for Linux to use one of the PT_*OS constants; however, I >>> generally believe it is better to try to be as inclusive as possible. >> >> I'd prefer not to add a new PT_ value that, for the most part, means >> the same thing as PT_LOAD. It would be more appropriate to use a >> PT_LOAD segment with a new p_flag value, say PF_SHARED. Would that >> work? >> >> -cary > > That would work fine, and it does indeed probably make more sense. >