From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34473 invoked by alias); 17 Mar 2017 18:12:11 -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 34456 invoked by uid 89); 17 Mar 2017 18:12:10 -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=ah, ah!, H*r:ip*192.168.1.2 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-it0-f68.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gw3BJnNgFQa7sM9fdI+bTMP8wLkwpQ9x5hLxysASD54=; b=lRH6txRQsix8CeYH5r0BU7aLdq1PmyOWIsZGSGLOvsPaMpEjgllKB0oZKyBNwSMl3J 25r0jIxmnbI1HTkdUjehEE2tHZtsb9yjY0g1c9+LpyOu8V2r16svWC6kvDAbQv1GpdQD kPJ8CEf5Uk7om4qMzSSUbB4JszXsh60RTcSa3k5WvLs97EbMGbIuW+8YRFUR/mQHcJRK ZDkd9/H8JNBadi48s4bCHtJT5rTKwqvHRj3l2jsmZuzCToXnBxIcW4LePuvtFFYHGWc8 us2xKKEwLdxyP2DnZ+kcfFC7LuwLN186OK4GZHIAdl6IvMd3GpQq1lY17wcsdHZisHWP yf8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gw3BJnNgFQa7sM9fdI+bTMP8wLkwpQ9x5hLxysASD54=; b=GRRZbeZ/Iqpm8Qpegt0C70uAcW7WIC1vKP62yGhAz0TkqNR2aVbLUJE+6j3MUfag4T Yr7HW9dewVh4XTJEdhRAGuU3z/MJcbeCciVHqUJzUb3G2Md5lNeSdGRXYtgoB0Sv9ZnW k8NT9SAvZLqVBb5mso50+HzIVT2fMhzqKog5w62V91B/OGVJQxrwDWOGViEMemVkZGHT ubqf+qvHXoVszZaeRLFcUXk6gVHKuabXJDvsBeNTnnf+COcxj6V5wzEPXAwlK8iyL+sp QgvCIHGq7uKhm/YdSZYYF0xb5tlHv/9gXYVZSMrpiSQ4Q32/SCjlg30sEW8x6GQT43ot 1lNA== X-Gm-Message-State: AFeK/H23YjmWZOV9DVsZxry4ZoGYtJQSITyoe3GmaqBhOfozCJv5HphL4jZx9ZNy1te4lw== X-Received: by 10.36.116.71 with SMTP id o68mr4548252itc.60.1489774328360; Fri, 17 Mar 2017 11:12:08 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: ABI support for special memory area References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> To: "H.J. Lu" Cc: Carlos O'Donell , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: <7deac251-8f93-9241-3902-daf2abfdef29@gmail.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/msg00021.txt.bz2 On Friday 17 March 2017 02:55 AM, H.J. Lu wrote: >> 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. Ah! Now I understand the design completely (I think). Looks like Carlos understood this quite earlier in the discussion. You are saying that the interface - int __gnu_mbind_setup (unsigned int type, void *addr, size_t length); - is fixed in ld.so and also in the real implementation library. And, the real implementation in turn calls the actual-real-implementation, as shown in your libmbind code: int __gnu_mbind_setup (unsigned int type, void *addr, size_t length) { // in turn calls actual implementation return vendor_specific_mbind_setup (vendor specific types); } All these while, based on the current description, I was of the impression that your design allows __gnu_mbind_setup interface itself to be overridden in the real implementation, something like: int __gnu_mbind_setup (__nvm_kmem_t *nvm_obj, void *nvm_handle) { // actual implementation directly here in the body } So I was wondering how and hence most of my points were out-of-phase. > The question is what the possible info needed > for all memory types is. Thats too much to predict right now. And the current interface you defined also does not seem to be generic. For instance, my NVM implementation, though not complete, needs a totally different set of arguments. So going by the current design, I will have to use __gnu_mbind_setup (unsigned int type, void *addr, size_t length) just to call my real setup, without using any of the arguments passed by ld.so. Assuming I am in sync with you now, I would say that the pseudo code I showed earlier works for you as well as for me as well as for anybody else. In other words it is more generic. With that approach, there is 1. No need to update ld.so every time for every new mem type 2. No need to know all possible info needed for all mem types 3. No need to encode all types in the API (as Carlos said) We just use pointer to implementation interface - struct __gnu_mbind_context that I showed. And we can have a default struct instantiated in ld.so and a global pointer pointing to that. And later the global pointer can be made to point to the vendor specific struct, before ld.so actually calls __gnu_mbind_setup, thereby completing a successful override (if necessary, that is when special memory types are in use). Or similar mechanisms to override default struct instantiated in ld.so. There are many well known ways to override the default struct as we all know. Personally I think this would be a better way to provide the ABI support in a generic way. That said, I am OK to live with minor kludges and we can keep the design as 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. Lets add this also in the ABI support document. -- Supra