From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14686 invoked by alias); 18 Jun 2016 04:11:01 -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 14662 invoked by uid 89); 18 Jun 2016 04:11:00 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Therefore, H*R:D*gmail.com X-Spam-Status: No, score=-2.4 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-pf0-f174.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:reply-to:references:to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kztpSfZOmzJZLXKdKHHORgiZSV6UPefUU0OsUS2bstY=; b=bIVKctQflFceYvR6QuILUro+FufOy4Rrv9kJlmHuQtcLFQyN4+h25aQYbNaMVcxGT6 3/GYqVLvzNwsYgqrXhb8b7wBYT/87mrJ114l1p6ffNt/tWzjO7OmgCYJQeaxLC4scmsB JBGB1ISO9tyDA11j5Tdtp1Z7z7q3pFoicUfM9qIf8QghvrE11DUynZeA6SrQfVt5BTuH 3kgpIsF8Puz0ZcT3ikwvS5L/MUYcDIridGhvdgTvLg+XNFwMgdxWu3x4f3L88Za1mPel TLHVX5PmW6rL3PD23m+5QJO/HfvejURihziBz9Dxle88sizkS2LcZsI985jmdeT6I+jN g7ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:reply-to:references:to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=kztpSfZOmzJZLXKdKHHORgiZSV6UPefUU0OsUS2bstY=; b=AltSzLQk8Mktu/hAwhjv6tkB2vwkYEfG+zF2hY6pzH9XW1LIAHrtD/FTdovlH01Smf ipDU0UAcN9oMU4vwTg2y24h02JuHM9lfTEl/i5LS+hr44ZpqdgBGZb5aR7dlLKZoDkAr 9PTrD9beDglFqNTURjj3V7HjMgSFTgpc+TMKjIDLVICBrvxIfEREolqor+ieweSnJOSE 39f8FAqb2O6gdfn/9CUiuvSdQNCPlLs0DHlva9wDDhegXEEsKDkF0X3zm1V9JAbJwNIc peCGc4x2fj5lOZT0XLWsvdDPv0VDCpKPGzOvqL7YgA3Uij2YDgOMYCf81MXjwb3UYalm URGg== X-Gm-Message-State: ALyK8tKRcvOzPiy1U77xiBgQfYOOOolOrAGjuL6rlIlp/zqfhS0okyj2PbHFgik58zQ9UA== X-Received: by 10.98.216.199 with SMTP id e190mr6608807pfg.76.1466223057416; Fri, 17 Jun 2016 21:10:57 -0700 (PDT) From: Suprateeka R Hegde Subject: Re: GNU dlopen(3) differs from POSIX/IEEE Reply-To: hegdesmailbox@gmail.com References: <25bc0c78-19ae-8974-b142-bb57f21cdb3d@gmail.com> To: Carlos O'Donell , gnu-gabi@sourceware.org Organization: HEGDESASPECT Message-ID: <763cd6f7-e33d-8d14-c0ba-f4e5797ddfa6@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: 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/msg00023.txt.bz2 (I was away from work. Apologize for the delay in response) On 13-Jun-2016 11:21 PM, Carlos O'Donell wrote: > On 06/13/2016 10:48 AM, Suprateeka R Hegde wrote: >> Without provding libfoo on the link line, I could not get a JUMP_SLOT >> for foo. So I provided -lfoo for the link-edit phase and then renamed >> libfoo.so to libfoo1.so and also created a dummy libfoo.so without >> foo. This way, I could get a JUMP_SLOT for foo. This hack was not >> necessary on other platforms as foo gets a PLT entry even without >> definition. By getting a JUMP_SLOT, I could verify if LD_PRELOAD >> works in this case. > > Correct, you don't get a PLT entry for foo unless it's in a shared > library at link-edit time. > > Could you actually provide the exact steps you used in a GNU/Linux- > --based system to produce the final executable? > > My experience is that you will either see a failure at link-edit > time, failure at runtime (missing libfoo.so, undefined symbol foo), > and will never get to the point where you can run the application > and get a segfault. I'm curious to see exactly the way you constructed > the scenario. This is just to show there are ways to bring symbols to global space at runtime. LD_PRELOAD is one way. dlopen(3) with RTLD_GLOBAL would be another way, but on GNU based system it is not as per POSIX/IEEE specs. So I tested for at least the LD_PRELOAD way. Here are the exact steps: --- $ cat main.c #include extern void foo(void); int main() { dlopen("./libfoo1.so", RTLD_GLOBAL); foo(); return 0; } $ cat libfoo.c #include void foo(void) { printf("In foo\n"); } $ cat libjunk.c #include void junk(void) { printf("Junky\n"); } $ cc -fpic -shared libfoo.c -o libfoo.so $ cc main.c -ldl -L. -lfoo # Gets a JUMP_SLOT for foo $ cp libfoo.so libfoo1.so $ # Now change libfoo.so not to contain foo. In other words $ # not to resolve foo from startup libfoo.so. Keep it unresolved $ # for lazy bind to happen to a runtime-brought-in global foo. $ cc -fpic -shared libjunk.c -o libfoo.so $ LD_PRELOAD=./libfoo1.so ./a.out In foo --- As you see, program works fine and foo is lazy bound to foo from libfoo1.so, which has been brought in at runtime without being there at link-edit time. The same case would have worked even without LD_PRELOAD, and with only dlopen-RTLD_GLOBAL if the GNU dlopen(3) matched the spec defined by POSIX/IEEE. > Therefore if the application's global symbol references all must be > defined before it starts there is no possibility for dlopen with > RTLD_GLOBAL to add symbols to the global scope that can be used > to result such symbols, because they are already resolved. No possibility with current GNU implementation. But possible with POSIX/IEEE compliant dlopen(3). The test case works fine on other POSIX compliant system. All I am saying is, dlopen(3) with RTLD_GLOBAL also should bring in foo at runtime to be compliant with POSIX. -- Supra