From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90549 invoked by alias); 8 Jul 2016 04:33:46 -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 90533 invoked by uid 89); 8 Jul 2016 04:33:44 -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=whatsoever, Hx-languages-length:1767 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-qk0-f174.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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=O5Fp2fYAGglhBfcL+V2scjzRHt5PygJ5s5jk/BwWCXs=; b=HQ4cW71a/BlcmeML3qkXJYTr5H9IeeYn/1VfeTEg0fgriQeKtINF51TmXyzXiTXoZT 2209ydFxdoRJvh/59Uti1zoX8MKaoFtZYnzpaAFWG2E8L6UiZFkZ25wZP8CixrEGbehp A/E5fXKXF+W7O5/JutUtWwaLROqkab1rELejx3R3rw53PpyXwWwCYOWoRxCnDdWiGjTW I55+Z1CPNHvT25uJahU5VPHTMJo2ORv5GaRmw00fLeoBtBXBBxWn0PuIIYKGUjWAI0fr fiMI+g+5OxVjnXuB25eHpJotD3LyfE9W2cvSwmf6XgC1WL9IFLDGth2DjZkmH0lPzXR5 lA9g== X-Gm-Message-State: ALyK8tJ4yc5v+28wselFVVR45e/HjWQu6HYxNTJvj5JW95zTvlwCm8rR1ESqEJQltE64GDXJ X-Received: by 10.55.3.143 with SMTP id 137mr5101368qkd.154.1467952412263; Thu, 07 Jul 2016 21:33:32 -0700 (PDT) Subject: Re: GNU dlopen(3) differs from POSIX/IEEE To: Florian Weimer 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> <877fd5dr38.fsf@mid.deneb.enyo.de> Cc: hegdesmailbox@gmail.com, gnu-gabi@sourceware.org From: Carlos O'Donell Organization: Red Hat Message-ID: <69611e20-ed32-2133-274c-a30485e70f23@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: <877fd5dr38.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q3/txt/msg00001.txt.bz2 On 07/01/2016 04:46 PM, Florian Weimer wrote: > * Carlos O'Donell: > >>> 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. > > This particular ld manual page seems to be derived from the > ld/binutils Info documentation, which promises the same behavior. The binutils manual should not dictate glibc behaviour. Patch sent to binutils: https://sourceware.org/ml/binutils/2016-07/msg00104.html > I am not sure what the exact semantics of lazy binding should be. The semantics of lazy binding are purposely vague to avoid constraining the implementation. The reference to the symbol will be resolved at some point between load and call. Do we need stricter semantics? Do the stricter semantics give us something in return for the constraints we place on the implementation? > With IFUNCs, lazy binding is observable, and we know from Fedora's > BIND_NOW experiment that some applications assume that undefined > functions which are never called do not cause any trouble whatsoever. The IFUNC observes lazy binding only indirectly in that the resolver is called one or more times depending on (a) number of object references to the resolver and (b) number of threads concurrently updating GOT/PLT entries and calling the ifunc resolver. If there are relevant issues from Fedora's BIND_NOW testing that relate to gnu-gabi, then we should raise them in a new thread. -- Cheers, Carlos.