From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63204 invoked by alias); 5 Jun 2016 07:29:09 -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 56564 invoked by uid 89); 5 Jun 2016 07:29:04 -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=philosophy, coupling, reversing, inconsistencies 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-oi0-f65.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:reply-to:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=shxfTH3Je65jxc3KURDUXdnfZ6IgpdPzLKHoTEFVfNc=; b=KK5HIvgnmujvVzNN3r7ChU8+vJAJb3EU/af91dmBITpcfHTsVnZAFjKdVBap+XTm09 KiUyQUyY6uPbHrzDLgpqVvzw6XK4+kCK8Th8yks/kdBKZlO8dU0ORneWwGOYbVpekfcp ZZ8brNHZO4f59iMB6Oxc0ceaAsHpqsBSH1u8+byH1FznaQnWNZrRDWr2WyXnYZhxuPd7 lb9RK9dN1uyS3PY7Qas1thd8zEA4/LYrF2fTWCQU/l0b+467YEDxECI7lJc4ZkPug2ia vdi8RXOXtGyZjB50JJLTD5aTJixnuZ/AhfwsAGZYhOt+na3IoepCNysTQ+cBXg+Nhu9h fV2A== 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:to:organization:message-id :date:user-agent:mime-version:content-transfer-encoding; bh=shxfTH3Je65jxc3KURDUXdnfZ6IgpdPzLKHoTEFVfNc=; b=D0/y4zJO4sDrslt+JREgZq02bn8GHLdbLnv3sWKbhJS/WhmJntlN9dVCn+lmeF5ZNh 60ndgIVC83Puj3nwGqlSm16lYwghfIAX10S9YQqV2ECZ9vJvdHs91yUl7REhmkNisZ1y TXXyzyxwe/wh/7oMbAHg/6kdGajkNPmzFdrH03CGAJb/t6xuZkkKrABiUkX/OdTV7kzg Rjylq3zkDTo8FXJVj+vrwBIX4KeoV9zXSlmV/Y2YSS81C/hhRyH3JXutWAGY2rkaq0jd ZlkN/YtpdCN9B8EVTrZguogsVQU6Z7KFUuKXuQkbTzT8hNUr97mQaOZmME6UG9SU1vbI 3H/A== X-Gm-Message-State: ALyK8tJs3UL8kKIj/8dNHsyLCyDmvPFOR8Y3Xwh5olhQjojP0k+TI8vHIn16NF88HRUtxQ== X-Received: by 10.202.219.86 with SMTP id s83mr5962322oig.167.1465111741521; Sun, 05 Jun 2016 00:29:01 -0700 (PDT) From: Suprateeka R Hegde Subject: Symbol Resolution Inconsistencies Reply-To: hegdesmailbox@gmail.com To: gnu-gabi@sourceware.org Organization: HEGDESASPECT Message-ID: 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160604-2, 04-06-2016), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2016-q2/txt/msg00011.txt.bz2 Hi There are some inconsistencies in terms of symbol resolution and library search mechanism. Consider this: case: --- $ cat main.c extern void foo(void); int main() { foo(); return 0;} $ cat weakfoo.c #include #pragma weak foo void foo(void){ printf("WEAK foo\n"); } $ cat defauktfoo.c #include void foo(void){ printf("DEFAULT foo\n"); } (creating archive libraries) $ cc main.o -L. -ldefaultfoo -lweakfoo $ ./a.out DEFAULT foo (Reversing the archive lib order) $ cc main.o -L. -lweakfoo -ldefaultfoo $ ./a.out WEAK foo --- The resolution for foo is based on the order in which it appears and not based on the binding type. However, adding a new dependency bar() in main.c and defining it in defaultfoo.c to forceload defaultfoo.o from archive libdefaultfoo.a, as in: --- $ cat main.c extern void foo(void); extern void bar(void); int main() { foo(); bar(); return 0;} $ cat defaultfoo.c #include void foo(void){ printf("DEFAULT foo\n"); } void bar(void){ printf("BAR from default foo\n"); } $ ar r libdefaultfoo.a defaultfoo.o $ ar r libweakfoo.a weakfoo.o $ cc main.o -L. -lweakfoo -ldefaultfoo $ ./a.out DEFAULT foo BAR from default foo --- In the above case, though weakfoo appears first in the order, the WEAK foo is discarded. It is clear that this is because defaultfoo.o is now forceloaded (because of bar) into linker's symbol resolution phase. However, even the above case (with bar) does not pick Default foo when both are shared libraries. In case of shared libraries, it is always based on the library order irrespective of binding type. Technically, as linker engineers, we can explain whats happening. But aren't all these inconsistent in the perspective of an application developer? Like: 1. Adding a totally new reference changes resolution of existing symbols. 2. Changing archive to shared library type changes symbol resolution. Now consider a case where we mark the reference to foo (in main) as WEAK (IMHO I am against the philosophy of assigning a binding type to a reference). In this case, the behavior is as per SYS-V gABI -- "The link editor does not extract archive members to resolve undefined weak symbols. Unresolved weak symbols have a zero value". Either we need a rule that says once a symbol has been resolved to a definition either weak or non-weak in an archive library, that symbol should not participate further in the resolution phase. Or a rule that says, if an undefined symbol is resolved to a weak symbol, link editor continues searching all objects and archive libraries for the availability of a non-weak symbol. In the absence of such a non-weak symbol, final resolution shall be to the weak symbol. However, this latter rule also means, some work for dynamic linker or some sort of symbol_name@lib_name coupling. This is not about right or wrong behavior. This is about making a behavior consistent at least on the same platform -- GNU. -- Supra