From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61256 invoked by alias); 30 Mar 2017 16:40:51 -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 61244 invoked by uid 89); 30 Mar 2017 16:40:50 -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=perfect 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-qk0-f181.google.com 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=cKOhy//0zizhBSwS01Wfrcni3aLsZK7eLWV6F9EJudE=; b=Hl+DPmcJf7nTu+YnkDyQ5sN6n9dTySroprne37i+XYmTwj4eoSidGndLBVvKIKfavj aIUsVtj69CCIOFdnVWP/4kckAteqmWxHJi+L8CV/bxti5+6G3LElSq47+dsIMZklzRL0 8L+28fCUw3yJPO6R7d6FoOGpSrtPh69cCGFvhwVMwB4pWzwGrBcFJIlfLW4dkHZLPrqV Xz4FQgYnfnqXn4Q0GdbJwEG4lxaee/jLUdETRZLPXaogkg6B1Q6pA5+taHsv1dj2KN8z zYp6f5/LYQCuuGwhvOtt0un/2wJ1emAx4Vn+tct6+9XyH+2SZ3Wwl93FNGtnUH5UNEwZ UX1A== 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=cKOhy//0zizhBSwS01Wfrcni3aLsZK7eLWV6F9EJudE=; b=Zu7Rw01Nfj8qfh30nkr0+fyMRjDqY9n72CCPANkgizssszc1go1/avUToiU+8zKVDH m2T9MRD6eDFs6DHmNsZWydpcNHz5ZCUbQKwrs8BTYRWFB80i2jspYkTC7f1QuDbLHS1Y XamSYSjZxKIzeetvY4SmItasI3K2A41WHCUhBPs+f2QIabftJkhHLy36k/8AmH5muKxg opRGXVuSUCW2ziDaYNUWfIt1uS3kmzGXGae7so5j7YKcIfiTqvZGNYcgdsjUANRWmcWO i+tdSzq7XqJZAIr4NlRB6lHDhmygYYhynMSJ7BMHoq7jFHhk3815LB3O7M4EAtssZn5z VwjQ== X-Gm-Message-State: AFeK/H3TWUtW7u4dSmT/kuM6WsYpR3IzDG09rLZ5G0rgiOSibVaPqwJy5dRF6/2TCFOeb55b5UVmi0a+oQBgyQ== X-Received: by 10.55.116.70 with SMTP id p67mr642860qkc.216.1490892049151; Thu, 30 Mar 2017 09:40:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <96294553-8088-0a9a-3957-1006743619d5@gmail.com> References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> <7deac251-8f93-9241-3902-daf2abfdef29@gmail.com> <96294553-8088-0a9a-3957-1006743619d5@gmail.com> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: RFC: ABI support for special memory area To: Suprateeka R Hegde Cc: "Carlos O'Donell" , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00028.txt.bz2 On Thu, Mar 30, 2017 at 9:02 AM, Suprateeka R Hegde wrote: > On 03/27/17 21:45, H.J. Lu wrote: >> >> There is a way to support GNU_MBIND segments without the glibc changes. >> Instead, dl_iterate_phdr >> >> int dl_iterate_phdr (int (*callback) (struct dl_phdr_info *info, >> size_t size, void *data), >> void *data); >> >> is called via the .init_array section to process GNU_MBIND segments in >> executable and shared objects: >> >> static int >> callback (struct dl_phdr_info *info, size_t size, void *data) >> { >> Compute the load address of the current module. >> if info->dlpi_addr == the load address of the current module >> { >> check ELF program headers and process GNU_MBIND segments >> return 1; >> } >> >> return 0; >> } >> >> static void >> call_gnu_mbind_setup (void) >> { >> dl_iterate_phdr (callback, NULL); >> } >> >> static void (*init_array) (void) >> __attribute__ ((section (".init_array"), used)) >> = &call_gnu_mbind_setup; > > This looks very ideal and perfect and matches my requirement too. Are > you suggesting this dl_iterate_phdr(3) as the way in your proposal > instead of the __gnu_mbind_setup? Yes. > Or are you suggesting that for all the implementations that need > different arguments (like that of my NVM) compared to > __gnu_mbind_setup_v1, we go with this dl_iterate_phdr(3) way? __gnu_mbind_setup_v1 is removed so that it will work with existing C libraries with dl_iterate_phdr. > I am OK either way. > > 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. > 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. -- H.J.