From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13687 invoked by alias); 19 Mar 2017 11:39:02 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 13657 invoked by uid 89); 19 Mar 2017 11:38:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=questioning, Hx-languages-length:2673 X-HELO: mail-pg0-f67.google.com Received: from mail-pg0-f67.google.com (HELO mail-pg0-f67.google.com) (74.125.83.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 Mar 2017 11:38:58 +0000 Received: by mail-pg0-f67.google.com with SMTP id 81so7757815pgh.3 for ; Sun, 19 Mar 2017 04:38:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=B06ebAvkrjF7bWrUWbpDVgSuIkDG6a32v3sTjegsxZE=; b=WqLnZaXLSRS7mlxWfSM+roEcWt4Z9NeW1LsAgBLLiJyj0HD/hHj1RVA/M/K4rWplTa /DCrXfckuwO7JaoO9LWQ6lEaWvZEQO6iDJ3O0fT7Uae71mv0QUzFhbbpzK+XJy+cViWH R6Lhf5Y5qernOnzOFY66gUORM8TGekOx28IvpY4cHcnTorMKqKXrYj+8769bMRt3QPP3 DiTUuG50sTBu4Ri7RLrV9bjZGDfyuG7vK4D/sOjaAPZhv54kg9BoCK0x4CVy8zU3SUPL 8k95w7Qa4C6ukPwvzx54UPLxuL/RTUt+elmX+l7dS8Fc69mzOtp97+JyiQ37qNdx499j CtHw== X-Gm-Message-State: AFeK/H2TCrjXvxdxuDjuzass0h6two7JgZX10wXiUbvmWGJ+0y7+KAX3fTErwkce1BQwgw== X-Received: by 10.98.101.71 with SMTP id z68mr25999013pfb.25.1489923537611; Sun, 19 Mar 2017 04:38:57 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-71-80.tyqh2.lon.bigpond.net.au. [58.160.71.80]) by smtp.gmail.com with ESMTPSA id 78sm26963437pfm.122.2017.03.19.04.38.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 04:38:57 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 33B3EC06B7; Sun, 19 Mar 2017 22:08:53 +1030 (ACDT) Date: Sun, 19 Mar 2017 11:39:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: Binutils Subject: Re: [PATCH] Support SHF_GNU_MBIND and PT_GNU_MBIND_XXX Message-ID: <20170319113853.GX4983@bubble.grove.modra.org> References: <20170315224617.GA23626@intel.com> <20170317033836.GQ4983@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00268.txt.bz2 On Fri, Mar 17, 2017 at 08:58:02AM -0700, H.J. Lu wrote: > On Thu, Mar 16, 2017 at 8:38 PM, Alan Modra wrote: > > On Wed, Mar 15, 2017 at 03:46:17PM -0700, H.J. Lu wrote: > >> Any comments? > > > > Doesn't pass my sniff test. > > > > You say that management of special memory regions doesn't belong in > > the kernel or glibc, but will be handled by a vendor supplied > > library. In that case, why must ld.so run your magic > > __gnu_mbind_setup function? If ld.so doesn't need to run > > __gnu_mbind_setup needs to called with memory type, address and > length in executable, DSOs and dlopened DSOs before constructors > are called. I presume if it is supposed to work with dlopen then you're saying __gnu_mbind_setup will be called for the executable and each DSO. ie. We're not talking about a case where __gnu_mbind_setup is called once after the executable and all DSOs have been loaded. If that is the case, then yes, it is probably most convenient to have ld.so involved. > > __gnu_mbind_setup then there's no need to pass information to ld.so > > via special segment types and flags. > > > > Just have the application call __gnu_mbind_setup. The function > > can take the address range(s) requested as a parameter rather than > > putting them into the executable headers. It shouldn't be difficult > > for the linker to arrange such a call on application startup. > > > > The goal is to place data in special memory sections via attribute. > To place an uninitialized variable, foo, in a mbind bss section with > memory type 1: > > int foo __attribute__ ((mbind(0x1))); > > To place a variable, foo, in a mbind data section with memory type 2: > > int foo __attribute__ ((mbind(0x2))) = 1; > > To place a read-only variable, foo, in a mbind rodata section with > memory type 3: > > const int foo __attribute__ ((mbind(0x3))) = 1; I think the relocatable object support is fine. It's just the new program header I'm questioning, and only because it seemed to me that ld.so didn't need to be involved. If ld.so isn't involved then you can support the feature on older glibc. > How can linker arrange calling __gnu_mbind_setup in executable, > DSOs and dlopened DSOs before constructors are called? By making that call the very first constructor. I'm not sure whether you want to run before DT_PREINIT_ARRAY constructors (or should!). It would be easier if not, because then you'd be able to hook into crti.o _init and pass parameters more easily, either using the same trick of a weak __gnu_mbind_setup call or have ld edit the _init code. -- Alan Modra Australia Development Lab, IBM