From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130767 invoked by alias); 24 Feb 2017 02:59:46 -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 130685 invoked by uid 89); 24 Feb 2017 02:59:37 -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.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,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-f180.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=Ze/xo0w53Rxk8haKMaF5YWSd9t4YGQGynFTF2GDIUB4=; b=TJylk4JN/6ONOsMhEyoAqxAIhra8l1WmOoExCNQWOqL1gU05uDBg76iP0ENsRKeizy zHiMhrPxd+6Ido8ImnnDTZv96y4TGT53phfbIaLI6v6G14frJNQEHohPHW5rHv0z+ACX 5DrXyY37jNCN/h5ytJKjLmK8zrBPaHfz3mE3oktozgbes/jvFO+wHgVm7yZtGdIDfwSu Hd6h/okugt9QDQ1x4lkCl0XKf1oe+URNcidckLE4iTaQfayVBoEhIAfztrPHYd+TOpyT /wEU29itTflQ7AGGoT0XBLLVMrYoa975X18CLijVQxB4c3BDOOSG1DDHs4cZqbNOZTD6 RiMA== 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=Ze/xo0w53Rxk8haKMaF5YWSd9t4YGQGynFTF2GDIUB4=; b=hTubYhNjivwiTBr2B80lzy045RTMsf9WZ15MjB38LxYf0zy9HjTjN0zT3i2TKhM5NG xJBnDgYuycUMcwFLUTPPlfU020vRMQ3c3Uyp60US2X106C6oWsEAhV1u+0vdQ5nOR2nH 8+6mOayF9Re3mrsYP2kkArVMHGt57/A2ELu25LR6+O2tIdovMKnBKmrD1K8XLcPNCuxd 09SlyJZG6wdlZTwNdSsQQklO3SmGi7FCcqH9cZQxae7jr8ajGXa5XgPXTVyiS7cl3vZS V/myEfZ7HSXF/IYVF7EWOZg+u4Q3TyJYfEFt81lDlpJWTgxsjHp+NJ4+MlICg6kac/Tt 9XEQ== X-Gm-Message-State: AMke39lMxrkdN+ymmtTxld22gFFNVQ4XYBcofSUoi+csT+G1rW3kJYuC1gm1mrO/kzGhDnB7SlXzevPjunnt0A== X-Received: by 10.237.46.129 with SMTP id k1mr485346qtd.135.1487905174632; Thu, 23 Feb 2017 18:59:34 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: 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: "Carlos O'Donell" Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00002.txt.bz2 On Thu, Feb 23, 2017 at 4:55 PM, Carlos O'Donell wrote: > 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? Since __gnu_mbind_setup may call any external functions, it can only be done after everything is loaded and relocated. > 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. 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. >> 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. > 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. -- H.J.