From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110104 invoked by alias); 1 Jun 2017 19:15:54 -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 107216 invoked by uid 89); 1 Jun 2017 19:15:52 -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.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=interest X-Spam-Status: No, score=-1.8 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-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Jun 2017 19:15:50 +0000 Received: by mail-wm0-f44.google.com with SMTP id 7so491680wmo.1 for ; Thu, 01 Jun 2017 12:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C1wf31MvPxpQ9C6GwxQywpIExJZ8kBXrKFps+cdAjuU=; b=mterR9J77TokMv3mO3+D5b/Su77ygAFMIwkNbZkJgpEJjySFFAPvV8qRGhsj/4FanC othOUxoz2g+O6iy7mWcUHDk0hHAiQe9iWuIFzhxnA78x6ZfDRB1oTsAPa2+q/PMsqXCp QZ1i9tNGADv9DbawPBeXG2Zf2aigiqwAXgMA9syliuntmM2UHeQ8u2Y7rMFxKaGRUw8K dDl660xmqUvZOPenSYkWUJnmLcwIuO2qYZORVypkFFUhYkXoZQB9JxYmtWrih1o2RwnJ 4qYN3tjSlnsP1fTtU78Y77i9NcrZBlGlXoSx4krT7qfuAqEH8A4ZJuIEzdSl2mWVrULp p+ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C1wf31MvPxpQ9C6GwxQywpIExJZ8kBXrKFps+cdAjuU=; b=OqFNdEYkLMyF4GsYAqdE8xU/fCgVsFyhuF+N0Cn5+Dwyh8tYuycPXUw+1IvWy7WToR AYARkSKYJT4TJ1i9QI2HxxNmi6lGb0wrfMBOBmGBLyoJPdLdfm8A8FX/OxtclHQxaAnO MPaFZkfUDKkZxQxrYJtoANC5+sxdgI72Ymbw6fiqxqbpuyp1riqzdoseXIW6mIjFAxEs GU4N8XlzxjLURMYHK2fnQ8Fvj+6x+3Aqf4okwILOqV3xUl8OU6cohOwt2BrznZflOea7 ZVWkrojt/6ZrgLF4QHmLl3mXvaBsVNkOauGKJaTdhLQ5/EEycMLBGqr3sP4hixyavJsc H/+A== X-Gm-Message-State: AODbwcDKxDGAl/msJWaT3Xfkwga7dfkLhx0rkuoE9C/4eJ5gZQs8ZGqD CMyPOc4Z5sZ123gE+aZctdBU1lamNQ== X-Received: by 10.80.151.243 with SMTP id f48mr3049414edb.54.1496344552892; Thu, 01 Jun 2017 12:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.212.11 with HTTP; Thu, 1 Jun 2017 12:15:52 -0700 (PDT) In-Reply-To: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> References: <5d71c4e4-19d2-3861-e212-5e86d29c53fc@zytor.com> From: Cary Coutant Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: gABI extension proposal: PT_SHMMAP To: "H. Peter Anvin" Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00018.txt.bz2 > 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