From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98520 invoked by alias); 13 Jun 2016 17:52:05 -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 98506 invoked by uid 89); 13 Jun 2016 17:52:05 -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=Hx-languages-length:1305, H*RU:209.85.223.178, Hx-spam-relays-external:209.85.223.178 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-io0-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=+Tb+mdsUK6h4kcuhFMO46dGY63u1adT4McZykcSzZQY=; b=XlHx7WWYMtWH47fMCV+m3QVI1dK0c9gIgjcv+h9GIem10eu6A18dIMhVvwhVjiJcHm G23/ecEhtFkd9bJc1P5EXU0F9MC5Z20L2626qCsinQbWoqwXXpErZQ9V3TpuYfKttKud rfCi8zeRLxtOKYbYLJIUTtSZcwDVnGHoWFswyZlnhGtM/adTlGbtej4YyJP+vBSGTXyk JhtILNj9oEHL0A2qxD8xzYezxM/Whyu82JyQ3lVyYYNsRKSaVbzqXdt2e9vjSwpZ4CTA 9vf32ycxKAp2YJhW/Ulr7DPoufGUQ4aUHoBaJ3M8+sJvG8BU0sUmZtLvH2/tDyjzWeJG tfRg== X-Gm-Message-State: ALyK8tIs7FI6Rz8PxYwTKaLUB2ISaF4tOaAwmsibn4abEoO0O0YEGM970+oGRjtOBpe/jO/P X-Received: by 10.107.8.26 with SMTP id 26mr24194039ioi.85.1465840322090; Mon, 13 Jun 2016 10:52:02 -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> 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.0 MIME-Version: 1.0 In-Reply-To: <25bc0c78-19ae-8974-b142-bb57f21cdb3d@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q2/txt/msg00019.txt.bz2 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. 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. -- Cheers, Carlos.