From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75822 invoked by alias); 20 Mar 2017 18:23:03 -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 75803 invoked by uid 89); 20 Mar 2017 18:23:02 -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-f177.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=U83wA8bqnFI8GJy7b3iu5aQfvh4wNyjQi1ndfCMLSLQ=; b=QpzhJnqVTSAcXa9zipRHVcvpPJiutbPzAG3UtrkywB+XWMejlkddscwO2ll/CUKbND uFlguAMokVHxsDQxzAITOqDxwMoOWPYjdSSa6rpqzXHXUPo5r9DiWOTipm9w+4nImidL oxVHr2zuKhHbwRX1Z0ILULJ0dCzmLdxDBq17DG3zhxvj3qGnoFqtZxiw+IR4Sh0CG5s1 QE0KPq5LvfLEqbppVMvg9b68WMVAvDnV9ghFMGHiTcg/oqeOkOl+PnT22uBBn4uR2wnN UVBGJt4RwueqesjVK6+CCQqmvxzj1xBv5EEPsQ6H5qM8PCmUfsx9NXciNj3TTgyDgwsT CF2g== 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=U83wA8bqnFI8GJy7b3iu5aQfvh4wNyjQi1ndfCMLSLQ=; b=quqc8bXSVEdmnSzqhP8LPj+wLEUkiC+oPQlDM5FSow0PuQWjmDKhX/RHMhP1wOZMhb bKD7xV2+alKwUduakDz7YlB0KlQhP7wYL9fEl3krQD9iUAuxb2jjzJ2a+T/asdoFJrnE xPB11Ky28wODr6JkUCtygLd1Kbsxa3kxvIF7jhWLMG2XNxW4hHME7aoeYxw5erztIf/K ooaDkEphgLdQ8JJU0PhFUZ9fcS2W9EG+8bC6jo2dHE8uSJ8lIokuhuLhgD6SIUfApdr5 9DtL6nw6xcY+Le6SNUb8rCxsOmt9z0TSTFp5M4qeFKzKocWFhnS1ljyr91CZ03UFhdp2 7Rtw== X-Gm-Message-State: AFeK/H30qN7ms6wg8KqHnK4pM9YA0J2m9yLe9cip1BVmjMS31y+l61z2nRwjvQjzNeQQUhxiZvyD9/zlCZLW5g== X-Received: by 10.55.197.82 with SMTP id p79mr25004175qki.24.1490034179647; Mon, 20 Mar 2017 11:22:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <7deac251-8f93-9241-3902-daf2abfdef29@gmail.com> References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> <7deac251-8f93-9241-3902-daf2abfdef29@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/msg00024.txt.bz2 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. We can keep it ASIS and add a new new one, __gnu_mbind_setup_v2, if needed. > 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. -- H.J.