From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103040 invoked by alias); 24 Feb 2017 00:55:50 -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 103020 invoked by uid 89); 24 Feb 2017 00:55:49 -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=-6.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=Hx-languages-length:2422 X-Spam-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM 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-it0-f41.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:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=exDMacLbjo+7dkfnuZ7/9NqI2UIApG/SXNWU2YvfsZo=; b=mE8851fxp9tCIbN68uITDqhxCASHLD42MMlH51lK/pA81IfjOsXAeH1uouGDQp30p3 SRdadoMbV6xEt4LvFJtE0YLwyDmkrzYJ4qvTW84e9JgaTXMFfQJv2rbNzUIw25/Mo7yd ONp6mAT70uP/CL6E22o6kJMg99SIzX2o57dbtYpSEDTbab5iUG7xGFkrJ7WvtE9VAMQ5 5xXhyKIOatOK5vbmrAzIlqvJq8Rr7DG/MVH3Hle9N3lURkRUIAvp0oKs5IwyfTAmBjcQ 52YmR+VeyvuD4tzjofP+8MfPI+WA22cRgGLIBVnZSkxrJd+Zax6uVkeS7RuM+wnQcvmY tDLg== X-Gm-Message-State: AMke39lb7rmBAsOT/9x3L4Xue9QAQNeYHt1c+U9CWMhcULvpkcL4lrNDLHRYGZdz+RZQtG0E X-Received: by 10.107.52.211 with SMTP id b202mr484335ioa.150.1487897746338; Thu, 23 Feb 2017 16:55:46 -0800 (PST) Subject: Re: RFC: ABI support for special memory area To: "H.J. Lu" , gnu-gabi@sourceware.org References: From: Carlos O'Donell Organization: Red Hat Message-ID: 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/msg00001.txt.bz2 On 02/23/2017 11:19 AM, H.J. Lu wrote: > A system may have MCDRAM or other types of memory in addition to > normal RAM. Here is an ABI proposal to allow placement in a section > whose sh_info field indicates the special memory type. > > Any comments? > > H.J. > --- > To section attributes, add > > #define SHF_GNU_MBIND 0x00100000 > > for sections used to place data or text into a special memory area. > The section names should start with ".mbind" so that they won't be > grouped together with normal sections by link editor. The sh_info > field indicates the special memory type. > > To the "Program Header" section, add an inclusive range of segment types > for GNU_MBIND segments: > > #define PT_GNU_MBIND_NUM 4096 > #define PT_GNU_MBIND_LO (PT_LOOS + 0x474e555) > #define PT_GNU_MBIND_HI (PT_GNU_MBIND_LO + PT_GNU_MBIND_NUM - 1) > > The array element specifies the location and size of a special memory area. > Each GNU_MBIND segment contains one GNU_MBIND section and the segment > type is PT_GNU_MBIND_LO plus the sh_info value. If the sh_info value is > greater than PT_GNU_MBIND_NUM, no GNU_MBIND segment will be created. Each > GNU_MBIND segment must be aligned at page boundary. The interpretation of > the special memory area information is implementation-dependent. > Implementations may ignore GNU_MBIND segment. > > Run-time support > > int __gnu_mbind_setup (unsigned int type, void *addr, size_t length); > > It sets up special memory area of 'type' and 'length' at 'addr' where > 'addr' is a multiple of page size. It returns zero for success, positive > value of ERRNO for non-fatal error and negative value of ERRNO for fatal > error. > > 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 Why does it run _after_ all shared objects and the executable file are loaded? Why not let the dynamic loader choose when it needs to setup the memory? > 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? What if the binding would work if ADD was any value? -- Cheers, Carlos.