From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80057 invoked by alias); 18 Jun 2016 08:00:49 -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 80046 invoked by uid 89); 18 Jun 2016 08:00:47 -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.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=ranging, HX-Received:Sat, relocate, writable X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS 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-oi0-f50.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lkkWVN1jeCgG5U8eSaT/NP1fwKd6QZty/gXHw8MfnFI=; b=fPHwD5YjiTfLMBA5Sbw9l5qKsw+bovjY392cHohFBkALRqQq0Sv0AJxqRk0qnCefL4 wzlTnqms3zLZWdEpiPanPHoO5phShtcap2m/0uR6I7sltF8OImwTd5MZeaMa+ywubCZt wqvjc1f5nJWSuDiyayEKDy4fY69q8bIavX72qzyY5+c0sUcK2nlvIV6/BcEC8ZMO6CqB HA6kYP1edSeC2nDoaG9JjO3F2FeDtbym7bdUn/qau1dBOsJRxo/EIV+Ryi9novNj7d8J iqdKJh2erdr+vRbJpIkwYhC3LcBIdfqvMn6Cwsi6hnYiX4C2E4NXV4G5dQj349AX+ssS Iv0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=lkkWVN1jeCgG5U8eSaT/NP1fwKd6QZty/gXHw8MfnFI=; b=Kz3WvH/OwfAoHKrvvTA1y5pKJmxz8kVM7eOvY/OxYCme+jjwnHYuoubAaXyRpily1R zLHgkiQ975BugV+9d893uhBWhzTfpKG5UlL8xYGempQachVnYBpKE3KR340Pg2J/7/fy pxTk6lq/H6f8wD4WW6wtWpzoo138bTlGu2LC6EtrxeN+WXaYz86uwvH3XwqMTSW3nXHk iySVJxE2RmSP94oZVMKtQz/j39WWo9qB9BtmQgvOO+q+PgLIQBZvglqa+jd5/l/m71sT oSw0CYrJMWTcjJJy3BR2aaDMXW0v+ruYq6AN5PHUdmTQqpqOGcovWo97VuwmAqhWGeNy SN8A== X-Gm-Message-State: ALyK8tLs0pesQ/3g1rrxd+N/kzrFGtLJA+zyPsLRU1SB2M5gzNylESEk8K3RdSS5Y/KDtA== X-Received: by 10.202.183.87 with SMTP id h84mr3551849oif.151.1466236843383; Sat, 18 Jun 2016 01:00:43 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: GNU dlopen(3) differs from POSIX/IEEE References: <25bc0c78-19ae-8974-b142-bb57f21cdb3d@gmail.com> <763cd6f7-e33d-8d14-c0ba-f4e5797ddfa6@gmail.com> <42a86c64-a042-0c0d-9601-49729816c825@redhat.com> To: Carlos O'Donell , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: <8fead36d-c757-038a-3914-146ebeee8830@gmail.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <42a86c64-a042-0c0d-9601-49729816c825@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160617-3, 18-06-2016), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2016-q2/txt/msg00027.txt.bz2 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) --- This made me think that GNU implementation also matches with other implementations -- that is lazy resolution happens at the time of the first call. > 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. The very use of --unresolved-symbol=ignore all for an executable link is bad in a way. > and no guarantees are made, > you can't make a happens-after relationship, and can't expect > 'foo' to resolve to the loaded 'foo' that came into the global > scope with dlopen. > > Perhaps in the future you want a mode where all lazy symbol > resolution is done before the first dlopen runs. Say we want to > do this to relocate the whole PLT and mark it read-only for > safety hardening. This is going to be a "mode". Almost similar to BIND_NOW. But not default. Even if decided default, a non-default (lazy writable PLTs) mode still exists. > 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. > However, because POSIX says nothing about when the lazy symbol > resolution happens, or anything at all about it, It indeed says something: --- 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 then based on the ld(1) manpage, I thought GNU/Linux implementation uses the time of first call. 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? (BTW, the above is already in place currently and is working as expected) 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. -- Supra