From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26205 invoked by alias); 23 Feb 2016 13:55:58 -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 26183 invoked by uid 89); 23 Feb 2016 13:55:57 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=amodragmailcom, amodra@gmail.com, pose, Hx-languages-length:1835 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,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: mx2.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Date: Fri, 01 Jan 2016 00:00:00 -0000 From: Michael Matz To: "H.J. Lu" cc: Alan Modra , gnu-gabi@sourceware.org Subject: Re: Specify how undefined weak symbol should be resolved in executable In-Reply-To: Message-ID: References: <20160223044029.GE10657@bubble.grove.modra.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-q1/txt/msg00016.txt.bz2 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). 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. 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. Ciao, Michael.