From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30367 invoked by alias); 31 Mar 2017 13:45:04 -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 30314 invoked by uid 89); 31 Mar 2017 13:45:02 -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.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=guideline, H*r:ip*192.168.1.2, executions, liner X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-io0-f195.google.com 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=pkHKRG9GsKehJNgVjSojIZNGca/ZRlBBz58MXWV5WPQ=; b=Sp4Ilkm8GG/rgPKXbsGDLem3mWTm3Odz/C6PV8JcgPDMT1KjBc2f/75866Re8LaKkL RqNrsf+XeRZxL0EbYoIrro9XTjUFqyBTX63wAIpWjv38dS7zx89+qOfY1njKzcMUA7J1 PtDSTlzNUpp8Tlx5KZu/Kjjho5yirrcURXqEezqgiBs5IT0ktVTRUWIKUbBfWSOG8CWn DM9xXgKo1ZakyXBTwROHkPeKdjehzuhsaG51I7Gir/HHCKKJQ6asA8YeEqfs8vIf77K1 /zMS2RE8KdynGeW9Ftj5vXbxOS0xr6He6oKE8A4+s6gD0c9yewpFFCypgR5lk8EKRLqT SJRg== 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=pkHKRG9GsKehJNgVjSojIZNGca/ZRlBBz58MXWV5WPQ=; b=b0oHxzjO+CevH5uXGopfgX5orRnhV0N+ny5UlsfHPtU2E/ZOovK194WmGjelAA+6m6 uSvqLWP1aomdbWf25mZ85GxGMKdOfb3WmY8FteghhxKEqvgNPTMDTbkgRmbScIpwZrjc mVFpcaW7QU0eyDi0QD3QrV1sKH2F699YigkhpCekI+hZlK3Uf2wwBuN8gDnEOGrrbjun T6S/XF6225RnkkJsSrrWxQGaYl3FTtEg7toZtIiV2SjTq0PA4/gSq8bi5bO3Y9sNZUU7 NUt4INAS+z5Eh+MaDIqqZJtkbNUibGLObQfqnwbLXDUIBnvy9yf6Wm7r2H8CrIH507uh THeQ== X-Gm-Message-State: AFeK/H2yff/KkPmUvJ0ovYk0oPGQE0YQNvhDrqHSlZ+rr2Xbyk7Gxr2YAyZMR+VvQSNjNw== X-Received: by 10.107.11.16 with SMTP id v16mr2035221ioi.85.1490967901280; Fri, 31 Mar 2017 06:45:01 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: ABI support for special memory area References: <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> <7deac251-8f93-9241-3902-daf2abfdef29@gmail.com> <96294553-8088-0a9a-3957-1006743619d5@gmail.com> To: "H.J. Lu" Cc: Carlos O'Donell , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: <35fce20b-20e0-3d0e-1957-f3df124a05ac@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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 170331-0, 31-03-2017), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2017-q1/txt/msg00031.txt.bz2 On 30-Mar-2017 10:10 PM, H.J. Lu wrote: >> However, I am just thinking that your earlier approach -- >> __gnu_mbind_setup -- is better when shared libraries with GNU_MBIND >> segments are dlopen'ed. They dont have to iterate all over again to >> reach their PHDR. Or what is the recommendation for such dlopen'ed >> libraries? > > It is true that dl_iterate_phdr is called by every shared object, dlopened or > not, to locate its own PHDR. Lets put a one liner on best practices or guideline kind of. You have already made it clear in the example code. I am just thinking of putting them in words too. Lets say something like, each load module is expected to process only its special memory segments. To mean that shlibs/exe need not do any book-keeping to avoid multiple executions of the special memory setup for the same load module. >> And this dl_iterate_phdr(3) not being part of any standards, may change >> in a totally incompatible way in the future. >> > > dl_iterate_phdr isn't in any standard. But it is in glibc. Given that my > proposal is a GNU extension, it isn't a major issue. Working with > existing glibc is a big plus. Awesome. Looks great. Thanks a lot for the new approach. -- Supra