From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54780 invoked by alias); 16 Mar 2017 21:25:32 -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 54768 invoked by uid 89); 16 Mar 2017 21:25:32 -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.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS 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-f173.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=w/jBfs5Oa1lyfYy73at9D4/WH5mL6AH5r1K8xgC2YRw=; b=RYTsDSuUT0S94TZnnFXiwvwuYpmi81Lbor1A/INoDcMtLNYqfaZ5LpyawgGTodpbom oYBeQtn5S8c31fOd7BZ4KsKM8aQmlqf8vhuyIuiN17QfzXCfpPlSbb15Yj/P1mdFcVXM 2O7ZUk1OJnA3csvTQeL4PXvJVFHP8gNe3GoayNsS426dWRbkXYGb+6SLBNJhvvJcDZW1 271Rs4kMVKWIvIXDPS1YIDIChSP83m4OpVMNF7jsNRTu1ZSBnpZM3XvX/1s0WOnTbIok 3K0I7AA+QPYkKXnPVBVejQxHXKf7oqL2So4CenZdp6rvr7lGH3n76sai8wT1CG8WrXcx DnzA== 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=w/jBfs5Oa1lyfYy73at9D4/WH5mL6AH5r1K8xgC2YRw=; b=L1nM+5C2piCMLJ/ryjJGNR0p2GE4d+RHRvuuhjjOTZ0URFv3nQcfrIafjArPWNAR9c IeFQ9uFW5kWPsc/e3Y9U+MVv1nzOy3FP3lhDn2z2BLPkLNVk4Xhqkq9STT2D6r0YY8E7 LcG9lcPiFkTyM+/FuisHuBoB7nvb8G8FFIiLeYx40AcWamtj2fcTUW25ZICeDZzgn/R5 iPYTYHrsJvGJjeU6z0QuGoK1FhbIMkktGGHOxk+EEHpKK/oa+mKSnNT3eBgd7iNwjhZs A4eu1//bCywjOYVIhfE8zPFRVE8lzf1ymJfZl2qH55P+yerIlB4yCriqQdVyTSMH08Hy TGGg== X-Gm-Message-State: AFeK/H1y2HxaknyGHNSqjIW4UPf2nM4TVdAjwKdF7X7OgpMCpSzNDmgpOF6OhJqOt6rMSIMG7QQBaQ/dMarDmg== X-Received: by 10.233.222.6 with SMTP id s6mr10997718qkf.231.1489699529731; Thu, 16 Mar 2017 14:25:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> <1d183289-5789-8443-7db8-59816bfdd44c@gmail.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: Suprateeka R Hegde Cc: "Carlos O'Donell" , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00020.txt.bz2 On Thu, Mar 16, 2017 at 10:18 AM, Suprateeka R Hegde wrote: > On 16-Mar-2017 03:33 AM, H.J. Lu wrote: >> Run-time support >> >> int __gnu_mbind_setup (unsigned int type, void *addr, size_t length); > > I still think the above interface is specific to MCDRAM proposal and is > not generic enough for other special memory types. I would prefer it > more in the form of something I showed. > > Or something even better than what I showed for the ABI support > documentation and hence glibc implementation. > >> >> 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. > > Let me rephrase what I want to know or what I am telling. Assume my > interface of __gnu_mbind_setup is as follows: > > int __gnu_mbind_setup (unsigned int type, __nvm_kmem_t *nvm_kmem_obj, > size_t length); > > Then, What is the expected way to add the default implementation for > this vendor specific interface in glibc? Because this differs from the > interface seen in glibc (from your patch). > > Are you saying we should use #ifdef for default implementation of every > vendor? And hence a vendor specific ld.so? I dont think this is what you > meant as this has lot of obvious problems. > > Or are you saying that we do not add vendor specific default > implementations at all in glibc and just keep one interface and one > default implementation that you have mentioned? And then the real > implementation (with a different interface) would override glibc one > (with the interface you have defined)? Yes, that is what I proposed. > If that is what you are designing, it looks like the overriding is > purely based on the symbol name and not the the full interface of the > function. Personally I feel this is a overriding hack based on > linker/loader symbol resolution magic. The goal is to link in special memory run-time only when special memory is used. Otherwise, every executable will be linked with libmbind. > Since ld.so is not meant only for programs with C style linkage, what if > the real implementation library is written in C++ and wants to export > only mangled names (interfaces) without any "extern C" kludge? Or is > this considered to be a standard C library call just like mmap etc.? Only the __gnu_mbind_setup symbol is used. We can change the second argument to "void *data" and make it dependent on memory type. But to support a new memory type, we have to update ld.so. I'd like to use the same ld.so binary to support any memory types even if it means that we need to pass info to __gnu_mbind_setup which isn't used by all memory types. The question is what the possible info needed for all memory types is. > And you may also want to define the flow for fully archive bound static > binaries. For static executable, __gnu_mbind_setup will be called on all MBIND segments before constructors are called. __gnu_mbind_setup in libc.a is weak and will be overridden by the real one in libmbind.a. > Assuming I am not missing anything above, if you still want to keep the > interface as defined by you currently, I am OK with that. But we should > at least add a couple of lines in addition, something like: > > "...which can be overridden by a different implementation at link-time. > Such an implementation is required to provide a C style (unmangled) > __gnu_mbind_setup function. However, the arguments and return type of > the function need not match the one defined here" What do you have in mind? You can't change return type in real __gnu_mbind_setup. Otherwise, ld.so won't work correctly. > BTW, what if the real implementation library also includes stddef.h? > Wont there be prototype difference if the vendor > implementation/interface is different? > The only type used is size_t. It should be the same for everyone on a given platform. -- H.J.