From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28839 invoked by alias); 30 Mar 2014 01:15:21 -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 28823 invoked by uid 89); 30 Mar 2014 01:15:19 -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-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 01:15:16 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id D6435744AE; Sat, 29 Mar 2014 18:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: binutils@sourceware.org CC: Roland McGrath Subject: gold regression vs BFD ld: __ehdr_start Message-Id: <20140330011513.D6435744AE@topped-with-meat.com> Date: Sun, 30 Mar 2014 01:15: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=jdowhun6mX8A:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=LiS9o7e13gKDEtfil3kA:9 a=4mpS2cFXageGsCWx:21 a=6yoYfcNnL4Nat8aE:21 a=CjuIK1q_8ugA:10 X-SW-Source: 2014-03/txt/msg00309.txt.bz2 With trunk on x86_64-linux-gnu: $ cat foo.s .text .globl _start _start: lea __ehdr_start(%rip), %r11 $ ./gas/as-new -o foo.o foo.s $ ./ld/ld-new -shared -o foo.so foo.o $ readelf -rs foo.so There are no relocations in this file. Symbol table '.dynsym' contains 6 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000000001c1 0 SECTION LOCAL DEFAULT 4 2: 00000000000001c1 0 NOTYPE GLOBAL DEFAULT 4 _start 3: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 __bss_start 4: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _edata 5: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _end Symbol table '.symtab' contains 14 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000000000e8 0 SECTION LOCAL DEFAULT 1 2: 0000000000000118 0 SECTION LOCAL DEFAULT 2 3: 00000000000001a8 0 SECTION LOCAL DEFAULT 3 4: 00000000000001c1 0 SECTION LOCAL DEFAULT 4 5: 00000000000001c8 0 SECTION LOCAL DEFAULT 5 6: 00000000002001c8 0 SECTION LOCAL DEFAULT 6 7: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 __ehdr_start 8: 00000000002001c8 0 OBJECT LOCAL DEFAULT 6 _DYNAMIC 9: 0000000000000000 0 OBJECT LOCAL DEFAULT 6 _GLOBAL_OFFSET_TABLE_ 10: 00000000000001c1 0 NOTYPE GLOBAL DEFAULT 4 _start 11: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 __bss_start 12: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _edata 13: 0000000000200278 0 NOTYPE GLOBAL DEFAULT 6 _end $ ./gold/ld-new -shared -o foo.so foo.o ./gold/ld-new: error: foo.o: requires dynamic R_X86_64_PC32 reloc against '__ehdr_start' which may overflow at runtime; recompile with -fPIC [Exit 1] $ I think when __ehdr_start was first added to BFD ld, it may have behaved this way too. But it works properly now. The key issue is that when the __ehdr_start symbol is in its indeterminate state, it still needs to be understood to be STV_HIDDEN so that it doesn't generate dynamic relocs. When it is eventually found that it can be defined and it is--a decision that can only be made after layout--then it will be defined as STV_HIDDEN, so it should always get static resolution. If at the end of the way it can't be defined (layout with no readable segment covering the file headers), then it is probably fine to get an error rather than generating the dynamic relocs that would be normal for any random undefined symbol--albeit, that is a regression relative to pre-2.23 linkers when users happen to use this once mundane, now magic symbol name. (I'm not sure any more if 2.24/trunk BFD ld has that regression against its own pre-2.23 behavior or not.) I think what has to happen is something analogous to what BFD ld does now: Add the symbol early on in an undefined or indeterminate state, and then define it (or don't) later on. It's not very clear to me how to do that correctly in gold. It would seem clearest if it can be done in define_standard_symbols. But I don't know what Layout::finalize (where it's created now) should do to find it and adjust it to point at the right segment. I also don't know how either case would interact with a user defining (in input or script) this symbol name himself, in which case (IIRC the BFD ld behavior) the user's symbol should be wholly unmolested (but it might be that BFD ld uses the user's value but marks it STV_HIDDEN anyway--I'm not sure). This is yet another time I've wished we had a common test suite for both linkers to verify matching behavior. Of course I understand why output doesn't match byte-for-byte and why the whole style of the existing ld testsuite doesn't mesh well with a more semantically-precise testing methodology. But still, harumph. Thanks, Roland