From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92898 invoked by alias); 18 Jun 2016 18:55:28 -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 92885 invoked by uid 89); 18 Jun 2016 18:55:28 -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.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=singular, forbid, undisclosed, boosts X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,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-qk0-f176.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=onhEv68/Octvz9V7tqqB6qqFLUnLyIRsAbVJyLHLHWM=; b=L492UJt+Oe/sC3F0kBrMSlf4H+2GyisiFGe3PfDDUTJbJHH1bZc4oGDZYN+cKBAwiA JnLNLSAIja64PZRoAy2doN0ziCHJWE7QEuYe9qWXLoB8HLp6GEnnX8VowUY3j6BLpHmf LP7eOIX1e0n2IjKTGwd4pEYbo0yCwLfBgQ5lL/IhDzNZzu8I7UsEVmpvv1gUKM1MCZqx nFY4NWKOuKFEKDwfg82a6ExynO95oWTiX6s86wB3iCVBvDxdGBDmS/GJK9UBT6UZ+HB2 qwwYcSiYguVUkss8UKZr/tOn65RrJYOtKp1jP6nLunxhDnRCOUVJqdm7kuguAjKN3rjq ms6w== X-Gm-Message-State: ALyK8tI6h7yMQxPgaVbfdxAKXYMHW/vTXDrPM50zrVBP7Zu24fIoN5MnW5LZmx9c6W0UJ6Nt X-Received: by 10.55.203.73 with SMTP id d70mr11397529qkj.116.1466276124341; Sat, 18 Jun 2016 11:55:24 -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: 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: <8fead36d-c757-038a-3914-146ebeee8830@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q2/txt/msg00029.txt.bz2 On 06/18/2016 04:01 AM, Suprateeka R Hegde wrote: > > > On 18-Jun-2016 11:02 AM, Carlos O'Donell wrote: >> On 06/18/2016 12:11 AM, Suprateeka R Hegde wrote: >>> All I am saying is, dlopen(3) with RTLD_GLOBAL also should bring in >>> foo at runtime to be compliant with POSIX. >> >> I disagree. Nothing in POSIX says that needs to be done. The >> key failure in your reasoning is that you have assumed lazy >> symbol resolution must happen at the point of the first function >> call. > > 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) > --- Note that those man page is part of the linux man pages project and are not canonical documentation for the glibc project. Often the man pages documentation goes too far in describing the implementation and beyond what is guaranteed. We can work with Michael Kerrisk to get this changed quickly to read "defer function call resolution to an implementation-defined point in the future, possibly as late as 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. >> You have read "shall be made available for relocation" and >> then used implementation knowledge to decide that _today_ those >> relocations have a happens-after relationship with dlopen in your >> program. But because lazy symbol resolution is not an observable >> event for a well-defined program, > > Yes. I agree very much. But making some massive enterprise legacy > application to become "well-defined" now is beyond tool chain > writers. I agree that inevitably applications of a certain size end up having dependencies on implementation details that in turn make them costly to port to other operating systems. I care a lot about our users, and I don't want to see implementations constrained by standards text that might limit benefits to them in the future. So any suggestions you have I'm going to weigh against what I think a sensible user might expect, not a singular enterprise application. >> If you were to _require_ lazy resolution to happen at the point >> of the function call, which is what you're assuming here, then >> it would prevent the above implementation from being conforming. > > Both are mutually exclusive. In my opinion, programs either want > immediate binding or lazy binding. Not an arbitrary mix of both. I disagree. Lazy binding provides significant performance boosts, but in a mixed lazy/now binding environment you can bind a fixed number of key security related symbols early to quickly determine if the application uses say "execve" and decide if access control, in a policy-less environment, needs to be disabled (execve disabled unless the application needs it). You argue that we should standardize on "bind now" which happens immediately at startup, and "lazy binding" which always happens at the time the function is called, ignoring any opportunisitic binding that might happen if the dynamic loader happens to prove it knows what the binding result will be. No, if anything, I think we should be less proscriptive about lazy binding. >> However, because POSIX says nothing about when the lazy symbol >> resolution happens, or anything at all about it, > > It indeed says something: Only for dlopen... > --- > RTLD_LAZY > > Relocations shall be performed at an implementation-defined time, > ranging from the time of the dlopen() call until the first reference > to a given symbol occurs > --- ... and it says nothing really, like it should, leaving the choice up to the implementation. This text is specifically geared towards shared objects loaded via dlopen, not the symbols in the binary, for which the standard says nothing. > And then based on the ld(1) manpage, I thought GNU/Linux > implementation uses the time of first call. It does, but it doesn't use symbols brought into the global scope by dlopen for this resolution. > What is the harm if we go by the existing documentation and under the > option -z lazy or RTLD_LAZY, make lazy resolution happen at the point > of function call? You forbid a mixed binding environment, you forbid opportunistic binding, and force the binding to be truly as late as possible. > And eventually change the semantics of RTLD_GLOBAL to match the > description mentioned in the POSIX spec -- ...relocation processing > of any other executable object file. I don't yet see the benefit in this except that you say some undisclosed enterprise applications need these semantics because other operating systems provided them. That is not a good reason to be overly prescriptive in the standard. -- Cheers, Carlos.