From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56148 invoked by alias); 28 Feb 2017 16:19:27 -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 56135 invoked by uid 89); 28 Feb 2017 16:19:26 -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.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=late X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM 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-f171.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=mYWmdTcNlt4upF2l/0gM/DHCu7jnHik/D6WYc/RJl7I=; b=DSTYmEJcckQx/kcwrkZNiYyAMBkZ1+HmW8ZGiXHTCBkSkmsD58v8Kz6PWYDT2MT80w Z+nRsvWOyUiNpNwlghMG9GSRikVZMXNGMP/rDE4XFwZKI/M4LcFpRXs4B2RE7E6MnIvM eHKMgg4KOGj+RHhPHrO9l11J+gTOdNS68tWP477lLsBtcu6ReDDv37F5mIQW6G3zycvO KTQkw2uP60X/+XcHhsu4sLZmce06OOeRoPukTL2BnviuM+Dc8lzlkMoUl29rni0WSoVL rl0oCP7KULM+MVXa6rVtxZPKBF3GTmQ6nJQtEMP+RtmZbr4f1EFmiBsbdkjnDJsvC4j0 qz5Q== X-Gm-Message-State: AMke39lf5DjClQL5TfKiKKjsMI/qk6ZEXls53KIojCJ+JLcpSTnPm0BJuo/n6DnFLuoMx5aj X-Received: by 10.200.50.165 with SMTP id z34mr3502152qta.205.1488298763851; Tue, 28 Feb 2017 08:19:23 -0800 (PST) Subject: Re: RFC: ABI support for special memory area To: "H.J. Lu" References: Cc: gnu-gabi@sourceware.org From: Carlos O'Donell Organization: Red Hat Message-ID: <4982fddd-e7bb-e7f1-d2ee-7aa73066bc8e@redhat.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/msg00003.txt.bz2 On 02/23/2017 09:59 PM, H.J. Lu wrote: >> Why does it run _after_ all shared objects and the executable file are loaded? > > Since __gnu_mbind_setup may call any external functions, it can only > be done after everything is loaded and relocated. Who defines this function? Where is it implemented? What does a typical implementation look like for MCDRAM use? >> Why not let the dynamic loader choose when it needs to setup the memory? > > 1. We want to be able to add support for new type memory by just > updating the run-time library of __gnu_mbind_setup, instead of > updating glibc. Which library defines it? Can two libraries define it? Does the dynamic loader run every DSO's version of __gnu_mbind_setup? > 2. Since __gnu_mbind_setup may depend on other libraries, we > don't want a simple executable requires libfoo and libbar, in addition > to glibc, nor make libfoo and libbar part of glibc. Why can't this be run in a constructor? Is that too late? This seems like a specialized form of constructor that is guaranteed to run before all other constructors? >>> int >>> __gnu_mbind_setup (unsigned int type, void *addr, size_t length) >>> { >>> return 0; >>> } >>> >>> which can be overridden by a different implementation at link-time. >> >> What if you _can't_ bind at ADDR? > > It happens on systems without special memory. __gnu_mbind_setup > returns a positive value and ld.so keeps going. Isn't this a violation of what the application binary requested? This is a soft-failure that that application doesn't know about. Might this become a security issue if the application expected the specific memory type? >> What if the binding would work if ADD was any value? >> > > GNU_MBIND isn't a LOAD segment, similar to GNU_RELRO: > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x000000 0x00000000 0x00000000 0x54624 0x54624 R E 0x1000 > LOAD 0x054e9c 0x00055e9c 0x00055e9c 0x001b0 0x001b8 RW 0x1000 > DYNAMIC 0x054eac 0x00055eac 0x00055eac 0x00110 0x00110 RW 0x4 > NOTE 0x000114 0x00000114 0x00000114 0x00044 0x00044 R 0x4 > GNU_EH_FRAME 0x048eb8 0x00048eb8 0x00048eb8 0x00ff4 0x00ff4 R 0x4 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > GNU_RELRO 0x054e9c 0x00055e9c 0x00055e9c 0x00164 0x00164 R 0x1 > > ADDR contains the start of a memory region within the LOAD segment. What are the constraints of GNU_MBIND then? Is it required that it covers only the SHF_GNU_MBIND marked sections which are part of a PT_LOAD segment? -- Cheers, Carlos.