From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112704 invoked by alias); 30 Mar 2017 16:02:59 -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 112679 invoked by uid 89); 30 Mar 2017 16:02:58 -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=H*r:ip*192.168.1.2, 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-io0-f194.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=TxwVLgWYCNEvTPt7CntD8sb5Ops4Q1/KozOgsqo7T+U=; b=HM3mU4xvJBVbYQKlJ9WLSYRB5xPUMa1Icd4v4Kw7dP0hwpVLe72adBzZJAQFuiPFt3 1pituySzFIb+z/BhWkIZaCKcFEVZ4RYTNv2+tsvWkuqnJQsIybS+CtbFFQrIdZqrhqPT moO2gOxJ1zswAK48JnOP/iTYQ+fGdZgiKMcrzZQ5U6p6zh8aS7uKuR3dDzZPYD7um1w7 yOos6wrl+wyNIQr2scc285b/7Kvd+Rz1RatUKz86L3QJflmelIcif9GecspFcw7Hi4L0 HzdzTxqEKy6FCoHRD7gntM38sCU+w3yVU9iEom/mlL2KJpHIP8yw1jkJ0DieVXBO4T5h qN2g== 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=TxwVLgWYCNEvTPt7CntD8sb5Ops4Q1/KozOgsqo7T+U=; b=Sl5zgYjnw56bGbnp2hCmR8O2to3JGbQzm8FZ75SVXax9PaDMYjlsAkU9Yk+kLas9la Ulk2yiFjd+LkOseN3drCfi7D33ZaYw3viNMQgTO8t07is9Z2+pyFvCUPp5n7XBhLVnCW GfGmOIuyOa+HlaWcXB+KuTYrgNkoJKJ7suM2t872r4c8PJ54vvpIu2cL7H0Imj/5SoCG cja5MudGF2f3PwF4a6rGGqTlSpA5kB90vDPsYKnoqjYObREmX5zTL0Yi9XI2xlvD+ivF qo/svEWZ4nEp/27zOts9BIWtu3tngZzT2v5A+gN3rH7AcuvuT1wHYdB0Pyp0xIovxkMl 76iA== X-Gm-Message-State: AFeK/H0cg6m7WGu/4LkyjhxC/mJ4qwIOyj+i71MxTHto5IaIuQsP2vb4Lmg1IxBxMFOxUw== X-Received: by 10.107.50.11 with SMTP id y11mr1343246ioy.10.1490889776836; Thu, 30 Mar 2017 09:02:56 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: ABI support for special memory area References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> <7deac251-8f93-9241-3902-daf2abfdef29@gmail.com> To: "H.J. Lu" Cc: Carlos O'Donell , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: <96294553-8088-0a9a-3957-1006743619d5@gmail.com> Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-q1/txt/msg00027.txt.bz2 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? 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? 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? And this dl_iterate_phdr(3) not being part of any standards, may change in a totally incompatible way in the future. -- Supra