From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12782 invoked by alias); 23 Feb 2016 14:11:15 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 12768 invoked by uid 89); 23 Feb 2016 14:11:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99 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=2924, 15201, 23398, D*2 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-qg0-f54.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WfgJ6uCqIvs3F10xkQYjb5FrFpp9CslRhNuxvtXB8C0=; b=agZzzXhY2dqvVt9oGWRtC7OktzWUHpDHbxgMcTL0A88hQL+EaPKPoViyr8oiC8Forz wPqJkw8tKqd+3rtKgR0QSxdzfKnOZ9MhVPHmcS+R55CGWxP4bHZrBroKmyepD0M1eGp8 2mqGh9nGJrRw1oGwbu6yJafW/5WOkYxXJNx/FTxLwQfKJ/GKYsH5f/z5mzeHdsJInI/K RWgLgExhZG1M8H9jQyp4c5c4Kgc36Rx0nzVRyz0hWiZW4FU+cDw7NZwk+ea7kgWxxDO8 Pj34iOHA+ve4Ztw6kEQAzZFEW9z99tEI6npI8uQzXn0F4zPFxsyKjqcdwk4gRmvAOCPZ egLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WfgJ6uCqIvs3F10xkQYjb5FrFpp9CslRhNuxvtXB8C0=; b=FrS123pDbfQmoZXoKPGBFkrCfsA37FKICzSzLwnNucAjfdJ+Wn2OwqGr9o5j7soIpJ o1hlWXNoKoqjyerKi4fe0IyZKRJkyj1NsU2A2VyJOfqjLdHoOf3vdwGKRtK5nS+SKNsf n1W6qle4wmY28TQMxfoQRjlHc2U9nDDDfKRittKnWHdaDh94aogQ0gR/V09dCRGsa18i i7TVCJpMNbidXs3SWHUnz+sBvGbkILcgCfj/vj7oUY+imZOl6aXWKcLCFp5gJq+C4zVH JiDqJLp3IViuORTDoEdy+orMFcnx9EojinRgutFQK9/+Nbkpg0rcLxgNiAdyTC8IUpDG GufA== X-Gm-Message-State: AG10YOS1yUWHulM3/KWtKyqFoUQzhNyijeuMya766QvPb5xn2Jl5bzfI5C1RLkWSXQmaycBj6bVJ8O1pSJcL9Q== MIME-Version: 1.0 X-Received: by 10.141.1.87 with SMTP id c84mr44354866qhd.1.1456236671569; Tue, 23 Feb 2016 06:11:11 -0800 (PST) In-Reply-To: References: <20160223044029.GE10657@bubble.grove.modra.org> Date: Fri, 01 Jan 2016 00:00:00 -0000 Message-ID: Subject: Re: Specify how undefined weak symbol should be resolved in executable From: "H.J. Lu" To: Michael Matz Cc: Alan Modra , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q1/txt/msg00017.txt.bz2 On Tue, Feb 23, 2016 at 5:55 AM, Michael Matz wrote: > Hi, > > On Tue, 23 Feb 2016, H.J. Lu wrote: > >> On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra wrote: >> > >> > However, that might be a bad idea. Lots of C++ code uses weak symbols >> > for functions defined in header files, and other objects with vague >> > linkage. These result in weak definitions in eg. libstdc++.so. I'm >> > not sure how many executables take the address of such functions and >> > thus might become DT_TEXTREL. >> >> Most, if not all, of programs will have DT_TEXTREL on x86 if undefined >> weak symbols require dynamic relocations. > > Hmm, that's less than ideal of course. Well, if the goal is to make PIC > and non-PIC the same, we could also go the opposite way: make PIC behave > like non-PIC, i.e. resolve weak symbols always at link editing time. That > of course would remove features (can't change libs at runtime anymore, if > they change in definedness of such a symbol). This "feature" never worked on x86 for non-PIC input. > Or, a third variant: change the compiler to emit PIC like code for taking > addresses of weak symbols also in generally non-PIC code, so we could > avoid TEXTREL. > > I think the ideal solution would be that last one, change link editor now > to behave like with PIC code, and eventually fix the compiler to not have > to generate TEXTREL. If we change ld now, all of a sudden, x86 binaris are marked with DT_TEXTREL. What we can do is to add a new linker command option, -z dynamic-undef-weak, and GCC passes it to ld only when compiler is changed to generate PIC-like code for address of all undefined symbol in text section. > Note that the existence of DT_TEXTREL itself isn't that bad: only those > pages that actually contain relocations will be unshared, so for the > example of crtbegin.o it's only one page per process. In addition > crtbegin could of course always be PIC code, avoiding the issue. > > I've looked at a normal c++ program (zypper) and the only weak undef > symbols are those from crtbegin. There are many other weak symbols, but > they are defined in the executable itself (it's mostly template > instantiations), so pose no problem. > > I checked cc1plus and found: [hjl@gnu-6 5.3.1]$ readelf -sW cc1plus| grep WEAK | grep UND 33: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@GLIBC_2.3.2 (3) 2924: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_broadcast@GLIBC_2.3.2 (3) 4861: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create 6330: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific 7205: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@GLIBC_2.2.5 (2) 7719: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete 9118: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create 11985: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses 12269: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once 15201: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@GLIBC_2.2.5 (2) 15794: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_wait@GLIBC_2.3.2 (3) 18312: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable 19108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific 19649: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ 19871: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable 20107: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_destroy@GLIBC_2.3.2 (3) 18570: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@@GLIBC_2.3.2 21461: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_broadcast@@GLIBC_2.3.2 23398: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create 24867: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific 25742: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@@GLIBC_2.2.5 26256: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete 27655: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create 30521: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses 30805: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once 33737: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@@GLIBC_2.2.5 34330: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_wait@@GLIBC_2.3.2 36848: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable 37644: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific 38185: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ 38407: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable 38643: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_destroy@@GLIBC_2.3.2 [hjl@gnu-6 5.3.1]$ Do you know how many of them lead to DT_TEXTREL? -- H.J.