From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32348 invoked by alias); 18 Jun 2016 05:32:40 -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 32325 invoked by uid 89); 18 Jun 2016 05:32:40 -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=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=relocate, relationship X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW 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-qk0-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=9olPxi7+EbJNh9gyeuBbGpq33w3F7bAVpc6sx7sjHeE=; b=F9ZUcXRZ9oDcpPX6mdlqZEqMQODZGYdenhDnrHIOsuQE7UohOm0fl2s5RQqCgVu/HA lxVNwU7OkDyuIrwR46NHqFIA4gsG3ThV+iOIe6eT6tn7ZkI3GCB2CRzkOVhRkn+ydnND NWWgGylPdvtMdsljCuv6kgSqkJTg30Vjz9S4vAl3L8/1Yavkiu0xxqzSgss0n2fnwlKq k1GwFXKDaspzHyaf+rqx4zBCfF4VehqYCFs+uebjM2VjVJkFtzcq1kGNUzGsz7rIDm5y jAwrcuZrVuQJO2b7qsimIymS8W08TWNCoR4eFbf1jpTm8kwxMpQ1x1W61/Z5JNptsNQ3 +zKw== X-Gm-Message-State: ALyK8tL+mEdB3onVgrFmyPV8y1/yBIwz7eBrlLQRuugaOrNH2l1htIG9OIxLhnIqcZpq/aRW X-Received: by 10.55.186.193 with SMTP id k184mr7281508qkf.184.1466227956692; Fri, 17 Jun 2016 22:32:36 -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> From: Carlos O'Donell Organization: Red Hat Message-ID: <42a86c64-a042-0c0d-9601-49729816c825@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: <763cd6f7-e33d-8d14-c0ba-f4e5797ddfa6@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q2/txt/msg00026.txt.bz2 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. 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, 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. 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. However, because POSIX says nothing about when the lazy symbol resolution happens, or anything at all about it, your argument is invalid. What you observe on other implementations is a detail of the implementation and a non-portable one. -- Cheers, Carlos.