From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104056 invoked by alias); 6 Mar 2017 13:25:24 -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 104037 invoked by uid 89); 6 Mar 2017 13:25:23 -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=depicts, H*RU:74.125.83.66, Hx-spam-relays-external:74.125.83.66, clarity 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-pg0-f66.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=4L5KaKZ6KeYepJ/5dXbUO+GU+zKAXf+XrsSql0OEFhE=; b=BsrtOXxYr95u3EsTr2lIyizjJOtlcvscUMg2L+0NSs1C32BmB+eYMeOtr/25N3C//B d/yfmfFZijsggduHKBDOBrxa5IZT6ue5wnLxmRyinwqocD45gZTqtlmBqS9BzP5KjUQL eifB1XD2ZdWx29dIEnkRBf2LcfJIa34Z9+YRvQq3apdXU/3sHBXk5SEsvdoqvTaGxtv9 dSsZSelTryB5FaZVawl0zKmiVr2RaeiHY5fuvOoRjVBTj5epd7g1Cbw6PEJhpg05VRts 54z830Ez1uO2xZHykOhSJCmTHX64yUjm+SRrzei3p+J/q2bEQnH2z7MeoWrRuwKxmGq/ ilZQ== 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=4L5KaKZ6KeYepJ/5dXbUO+GU+zKAXf+XrsSql0OEFhE=; b=V+9zLGqg3Q60vg7OIwxYVV4JBywMk7niuX0kvlmZkGCkKs2VPeuWHrKHrw4ftzPwKx zpZo6oyGnnrdLU4llSxIUaAqYjAEonC440FJbPcOutSmskngeYWLNKYy45qBJhZSuj6x pVAbMiVJSR2ZEKqGf3tFolqm4ycMscMWotKt8S3o6KCY8MSvOwsi0QZR6kq+SDK06enC J5vTkYqQZIts+JuDl9SbHkVHeJ7+4oewXd7FL310ZS+4CII9wA0zNBMgTmyLRcS1oH7U rzUmWnWQu61qP44A6Z4ehPmSU2E7tIUWR4/dXJRsflueAtqxuUt+TPnImq72XU9cqTWv SZKQ== X-Gm-Message-State: AMke39n4Wre+0CZJjCC+4zszRpR/F7FgtSig+Ohk/lWyh/AuZxkpogDyCf73GiQCinz/oA== X-Received: by 10.98.223.76 with SMTP id u73mr21104625pfg.147.1488806720915; Mon, 06 Mar 2017 05:25:20 -0800 (PST) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: ABI support for special memory area References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> To: Carlos O'Donell , "H.J. Lu" Cc: 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 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170306-0, 06-03-2017), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2017-q1/txt/msg00012.txt.bz2 On 04-Mar-2017 07:37 AM, Carlos O'Donell wrote: > On 03/03/2017 11:00 AM, H.J. Lu wrote: >> __gnu_mbind_setup is called from ld.so. Since there is only one ld.so, >> it needs to know what to pass to __gnu_mbind_setup. Not all arguments >> have to be used by all implementations nor all memory types. > > I think what Supra is suggesting is a pointer-to-implementation interface > which would allow ld.so to pass completely different arguments to the > library depending on what kind of memory is being defined by the sh_info > value. It avoids needing to encode all the types in the API, and just > uses an incomplete pointer to the type. Thats absolutely right. However, I am not suggesting one is better over the other. I just want to get clarity on how the code looks like for different implementations. On 03-Mar-2017 09:30 PM, H.J. Lu wrote: > __gnu_mbind_setup is called from ld.so. Since there is only one ld.so, > it needs to know what to pass to __gnu_mbind_setup. So I want to know what is that ONE-FIXED-FORM of __gnu_mbind_setup being called by ld.so. > Not all arguments > have to be used by all implementations nor all memory types. I think I am still not getting this. Really sorry for that. Would it be possible for you to write a small pseudo code that depicts how this design looks like for different implementations? Thanks a lot -- Supra