From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43403 invoked by alias); 22 Mar 2017 16:18:37 -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 43382 invoked by uid 89); 22 Mar 2017 16:18:36 -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=impression, HX-Received:10.107.58.131 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-io0-f193.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=2C89Ecj9CHwVtwOylmzMEZow8GnI8cGFTyTBSAi8g1w=; b=lIdp//kwR0GVyG3sRNMmmUc2BkT9h+uBcm0WEU8w1N7RGM+M9HSSLPue+5faIL4faQ xXEqqjc60vboof3S5fdz6aUWjbM26jHltXJYXco8qUW8QRAlbupmZmFQPIO4Z0dNo1vt j4irEiAnXHbaQZeBlf6vHNXYODDXCgevlVSq8DFFe7u6+beez4/jR2bSq4CRjmwfep3D tDrW4dyxO+m2lbeHe6jfycwo0y232BO8MXSEsX6acbir6OHBekKm9DKKwQ8iXOFHyEC2 NxPjAK9KE9Yla6gqVFBYeXn3ewiUG040ztukoiuGNgrVFzv4HOWhCPJtgWewRI6iu05+ +5AA== 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=2C89Ecj9CHwVtwOylmzMEZow8GnI8cGFTyTBSAi8g1w=; b=cXNKnvz8CsmIHD5HTJjUY1OlSRnxK4Y/rAe/C7zgHbVPpt6F5x/ztlTqhrjrrlohr/ w0zleSHg4L41Cu8I1oEKzfQBAYAnekSUgO7dxkXdIlA5QIoyl8ZDI6zSYPsz+PvS3O4/ 16kpVWRifvVsE7FL0i5AAYhRPLiSx40jEN4xaCFnyni32nvm/S0gSnX2B+wpZxN0gQPm oiuUpuAivcw+Y9PA2U8JcB7Nz3j9kDPU0uIKVA6a7u4VZzRapeGUnerUCrwPtvsAoIsO AmRHMcwI6a7CAjHrdND0r8oCjwWzt2dCVO+f0ahXOA6dmA+PIxJFtFZbgyscpr7QZ7L0 NYQw== X-Gm-Message-State: AFeK/H05jhV/Zrmqk7LVCxRhkDmqMVosSOHR6OGPAV1HDtZi5kPwkG3rFAL/Q55ppsZS9Q== X-Received: by 10.107.58.131 with SMTP id h125mr42416416ioa.37.1490199513570; Wed, 22 Mar 2017 09:18:33 -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> <7deac251-8f93-9241-3902-daf2abfdef29@gmail.com> To: "H.J. Lu" Cc: Carlos O'Donell , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT 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/msg00025.txt.bz2 On 03/20/17 23:52, H.J. Lu wrote: > On Fri, Mar 17, 2017 at 11:12 AM, Suprateeka R Hegde > wrote: >> 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. > > ld.so needs to call the real __gnu_mbind_setup implementation > with the correct argument. Yes and with my example code, ld.so calls with correct argument always. And its always only one argument -- a pointer to struct. By default pointing to default struct, and when overridden pointing to implementation specific struct. > We can keep it ASIS and add a new > new one, __gnu_mbind_setup_v2, if needed. Hmm :-) This also looks good. Though whoever adds this _v2 (assuming its me right now :-)), gets to ensure all the herculean compatibility hooks for _v1 are in place. But thats OK I believe. > >> 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. >> > > How about this: > > Run-time support > > int __gnu_mbind_setup_v1 (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_v1 with type, > address and length. If __gnu_mbind_setup_v1 must be defined in run-time > loader, it should be implemented as a weak function: > > int > __gnu_mbind_setup_v1 (unsigned int type, void *addr, size_t length) > { > return 0; > } > > in run-time loader so that the GNU_MBIND run-time library isn't required > for normal executable nor shared object. The real implementation of > __gnu_mbind_setup_v1 should be in the GNU_MBIND run-time library and > overridde the weak one in run-time loader. Looks good to me. -- Supra