From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95470 invoked by alias); 8 Jul 2016 05:00:51 -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 95454 invoked by uid 89); 8 Jul 2016 05:00:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=ranging, clarifications, singular, proposing X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qt0-f178.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=6Qiddy83Mm6Gzn5eOfo8yRhB9JzMrqSxDldUL/Fiz3I=; b=W3tC3lAQxAF5oxspx/S0gr/eFCZ/rtnI3BCdFecvql6YvNa3QoxLr3uKksIbxkvZz4 9YqOEcfkBK6/5+ArQFTEHKv2++tYVhchTJbGX9qFXOTOD+38RbonwJRDja4RqIeUi2ir B0cvJAsPEG5MvnHdAy1DRfv2qK/p8GdhqNBtHWrTYERvSZizwOQdQHgMI/oPfuxdPtMV 04rbuUSvAORlGX8dOy3sUgtSRNOZYOw8/ACaqpzCvzUyL0Q569EWYl9m9ov4rIqDgf5K KR4EykWtsRr9AuNS9WTTvtOJs4H8e82UnXQ4VzkBVLnSlnwQ6D/b4g8ST71xHQwSJ3Ap GKyg== X-Gm-Message-State: ALyK8tK4Bwmm8K9LXRVuDCPt/ZBaH5z1JNQPs6G4tXmWsT3eTB7sXMKfaROwK9WOK1qW2E1e X-Received: by 10.200.39.33 with SMTP id g30mr5857664qtg.16.1467954046746; Thu, 07 Jul 2016 22:00:46 -0700 (PDT) Subject: Re: GNU dlopen(3) differs from POSIX/IEEE To: hegdesmailbox@gmail.com, gnu-gabi@sourceware.org References: <25bc0c78-19ae-8974-b142-bb57f21cdb3d@gmail.com> <763cd6f7-e33d-8d14-c0ba-f4e5797ddfa6@gmail.com> <42a86c64-a042-0c0d-9601-49729816c825@redhat.com> <8fead36d-c757-038a-3914-146ebeee8830@gmail.com> From: Carlos O'Donell Organization: Red Hat Message-ID: <0d856592-5fcf-5098-79ae-803fb6b38ae2@redhat.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q3/txt/msg00002.txt.bz2 On 06/20/2016 10:19 AM, Suprateeka R Hegde wrote: >>> ld(1) on a GNU/Linux machine says: >>> --- >>> -z lazy >>> >>> When generating an executable or shared library, mark it to tell the >>> dynamic linker to defer function call resolution to the point when >>> the function is called (lazy binding) >>> --- >>> This made me think that GNU implementation also matches with other >>> implementations -- that is lazy resolution happens at the time of the >>> first call. >> >> That is not an assumption that developers should be making. > > Not as a developer. I usually read manpages as an end user. As a > developer I can clearly see whats happening currently. And whats > happening currently matches the description in the manoage too. They > are in sync now -- that is resolution at the time of first function > call. I have submitted a patch to correct this. First draft has been approved, and a second draft with clarifications for STT_GNU_IFUNC has been submitted. > All I am proposing is to make the dlopen(3) RTLD_GLOBAL semantics to > match that of POSIX/IEEE description. They already match. GNU dlopen(3) via RTLD_GLOBAL makes symbols available for relocation processing. POSIX/IEEE's RTLD_LAZY is the model for the executables own lazy symbol resolution and there the text of the standard says: "at an implementation-defined time, ranging from the time of the dlopen() call until the first reference to a given symbol occurs." In the case of GNU dlopen(3) I do not wish to constrain the implementation by saying exactly when the lazy resolution happens, and I see no strong justification to make it "at the time of the call" and to enforce global symbol searches from dlopen'd RTLD_GLOBAL symbols. >> That is not a good reason to be overly prescriptive in the standard. > > I think we have a very minor difference of opinion in the whole > discussion. To re-iterate, I am not proposing to restrict binding > behaviors either to be NOW or be LAZY. We can add anything in between > to optimize or secure. We can add them under an option as I said and > make it default too. The existing implementation is conforming as far as I can see. What you want is for the implementation-defined time to be documented as "at the time of the call" and therefore to be required to consider the symbols brought in by the dlopen via RTLD_GLOBAL. I do not feel that you have provided enough technical justification for this requirement. We don't know how this might impact the existing GNU userspace for the sake of a singular use case you present here. I could be convinced otherwise, but I am not yet convinced that the existing semantics should be changed. -- Cheers, Carlos.