From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130600 invoked by alias); 16 Mar 2017 18:22:52 -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 130586 invoked by uid 89); 16 Mar 2017 18:22: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=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,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-qt0-f182.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=oxBfN/WAX2cU+cqhOjp6ngMOlbKDdUVop46ylLZlKJI=; b=kMIfGzFKrgLItItykiShbgtfNHHGGcw4kFBfs0m+XNdjlZ05+KVo4gxJPggwHMRgHE h3LQ91l0x3AnYMxVhxTFSjwck64nM0kxklV9AslyZdkZz0SzLgCf/UOdGwJhMzXc61PL hOP3HfoP6jNHuSxohLn83VbQ9m0+xZAZSRYhb8rDe1p73oBiSRDa0QSY47OEawcVTscK iq5tePewBGQDIRW9i7EqcpN9BTygbxWu88kpBYMW4psfvTWxYCWSpK3vlPpFsXnT88g6 RIxX1rD+/Se1llrV8lkcxIPsRd0BRq04LZsa2nA0R5/swZi1GDtLl2hrmSwtyOxzJ/bu Ar4w== 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=oxBfN/WAX2cU+cqhOjp6ngMOlbKDdUVop46ylLZlKJI=; b=A6dIHQEA/W66y7s25cNbdIVtV85DJxba6dxju36hwREhwmzo6zyfh5C6v07Pa6NXa5 YH48dpNnA0VePsF9iEFUzywkSawj4Upo/AhW1LJQN26sAL63BTH8xRlbt1NLLbvU5WhV 3wrUguvhBkJzBsc/x0PMQAvF1calZ2ln8Nl4YR7Zt4VPtyqo55IoUFPRIT59AaOMTWlH YuxkmKdUVrWZPchUydoZ0LQSZdyQwTsqJADm855aNwmiF+SJvsgCNS4V4cLQPjgJbCoY DsyClXxrMwcf1dgrbxbhwsumu48TBzqIXOZZQYf1pmjXOhbkwFFInXgjGzuMh3cnrWle VcFQ== X-Gm-Message-State: AFeK/H3/JHDQb6x2oPamQPIBgzNjug8k/Nq9cdIj+1PUtbI4o+P2dehTOiKkuW1OT/IW3dKl41+9cKF/vDY4uw== X-Received: by 10.200.44.156 with SMTP id 28mr9793479qtw.48.1489688570028; Thu, 16 Mar 2017 11:22:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <13b95ec6-45be-b02f-bb63-bc1835ecf396@redhat.com> References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> <13b95ec6-45be-b02f-bb63-bc1835ecf396@redhat.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: Florian Weimer Cc: Suprateeka R Hegde , "Carlos O'Donell" , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00019.txt.bz2 On Thu, Mar 16, 2017 at 1:40 AM, Florian Weimer wrote: > On 03/15/2017 11:03 PM, H.J. Lu wrote: >> >> After all shared objects and the executable file are loaded, relocations >> are processed, for each GNU_MBIND segment in a shared object or the >> executable file, run-time loader calls __gnu_mbind_setup with type, >> address and length. The default implementation of __gnu_mbind_setup is > > > Is there a specified invocation order for the segments? > > Does the call happen immediately after relocations for an object are > processed, or only after relocations for all objections are processed? > > If the latter, why can't you use the existing ELF constructor mechanism for > this? As far as I understand it, the call to __gnu_mbind_setup would just > happen before the constructor calls. That is correct. The issue is to access the ELF segment header for each loaded object only once. There is no good way to get this info from constructor. -- H.J.