From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111621 invoked by alias); 31 May 2017 21:23:48 -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 111592 invoked by uid 89); 31 May 2017 21:23:44 -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=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=hoc, interest X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,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.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; Wed, 31 May 2017 21:23:43 +0000 Received: from hanvin-desk.amr.corp.intel.com (fmdmzpr03-ext.fm.intel.com [192.55.54.38]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id v4VLNheA015370 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 May 2017 14:23:44 -0700 To: gnu-gabi@sourceware.org From: "H. Peter Anvin" Subject: gABI extension proposal: PT_SHMMAP Message-ID: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@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 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SW-Source: 2017-q2/txt/msg00017.txt.bz2 Hello, 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. -hpa