From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16793 invoked by alias); 30 Mar 2014 04:25:27 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 16712 invoked by uid 89); 30 Mar 2014 04:25:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: topped-with-meat.com Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 30 Mar 2014 04:25:17 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id 1A88E74481; Sat, 29 Mar 2014 21:25:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "GNU C. Library" CC: binutils@sourceware.org Subject: gold vs libc Message-Id: <20140330042516.1A88E74481@topped-with-meat.com> Date: Sun, 30 Mar 2014 04:25:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Rt9WckWK c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=CCpqsmhAAAAA:8 a=FKNMxMXEJlEbqofvI38A:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2014-03/txt/msg00310.txt.bz2 On the glibc.git branch roland/gold-vs-libc is the trivial configure change necessary to let glibc attempt to build using gold as the linker. (The version check with that change is excessively loose--to boot, it admits current gold versions so you can test, even though they don't work enough.) i.e.: $ git clone git://sourceware.org/git/glibc.git $ git checkout roland/gold-vs-libc ... make the ld in your path and found by the compiler be gold ... $ mkdir build $ cd build $ ../configure --enable-add-ons --prefix=/usr The configure will fail the __ehdr_start check, which I've already posted on the binutils list about. This is not fatal. $ make -j... $ make -j... check This will get test failures for nptl/tst-*-static (all but one of them). (For me, there is one other FAIL, which is not a regression from libc built by BFD ld.) The affected tests are all statically-linked programs using cancellation, i.e. unwinding. I examined one in detail: tst-sem11-static. I assume that the others are all suffering from the same gold bug. I suspect the bug is in gold's .eh_frame optimization pass. For me (with trunk gold), the __EH_FRAME_BEGIN__ symbol (from gcc's crtbeginT.o--meant to attach to the start of the .eh_frame output section) winds up pointing at the end of .eh_frame rather than the beginning. In the binary created by BFD ld, the symbol points 48 bytes past the true start of .eh_frame, which is exactly the size of crt1.o's .eh_frame contribution (so what we'd expect given the input file order, albeit not what would be really right). The .eh_frame in gold's output is a little smaller, perhaps suggesting that it de-dup'd some CIEs and BFD ld didn't. I'm not sure whether BFD ld does .eh_frame optimization without --eh-frame-hdr (which isn't passed in this static link). Perhaps .eh_frame optimization just never really works with static linking because there is no right answer for what a symbol like __EH_FRAME_BEGIN__ should stick to? Hmm. If the first CIE there happens to be one that's de-dup'd then maybe it appears to make sense for the label to move to the remaining other equivalent CIE, which might be way off into the section. OTOH, crtbeginT.o is actually an input file that defines __EH_FRAME_BEGIN__ as a symbol in a zero-length .eh_frame input section. So it seems more unambiguous that this symbol should stick to that input file's relative position in the output section, which I think is well-defined in theory even when the input section is empty--rather than sticking to the immediately adjacent content of another (file's) input section going into the same output section, which if it's a de-dup'd CIE could be considered to have "moved" to elsewhere in the output section. At any rate, the symbol winding up exactly at the end of the .eh_frame output section, as it does, seems clearly wrong. gold hackers wanting to help gold finally get over the hump to being able to build glibc could try the build from the branch and debug this issue. glibc hackers wanting to help gold hackers achieve the same end could work on reducing and isolating a test case that demonstrates the misbehavior with the __EH_FRAME_BEGIN__ symbol without needing a whole pile of libc build .o and .a files to make it happen. Thanks, Roland