From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46229 invoked by alias); 1 Jun 2017 19:40:23 -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 45206 invoked by uid 89); 1 Jun 2017 19:40:23 -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=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; Thu, 01 Jun 2017 19:40:20 +0000 Received: from nexus6.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 v51Jc8qS002314 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Jun 2017 12:38:08 -0700 Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: gABI extension proposal: PT_SHMMAP To: Cary Coutant CC: gnu-gabi@sourceware.org From: hpa@zytor.com Message-ID: <6F367329-5B48-4702-B9F0-5637EF4A460D@zytor.com> X-SW-Source: 2017-q2/txt/msg00019.txt.bz2 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. --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity.