From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23137 invoked by alias); 1 Apr 2014 21:50:24 -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 23123 invoked by uid 89); 1 Apr 2014 21:50:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f41.google.com Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 01 Apr 2014 21:50:21 +0000 Received: by mail-qa0-f41.google.com with SMTP id j5so10259647qaq.14 for ; Tue, 01 Apr 2014 14:50:19 -0700 (PDT) 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=hiCmbGZWHkVZiHGAEUnfK5tn8x3DAGtvNUiLUAff/P8=; b=WY9jo4JM3VJLBxxA03dgezxhCiAlQslfrGCsXZpHChn5/NbaXvT3s3qM8DrXJ4GFve dKPvpOQc4UJccwstymcQI7bQaZy7KsPxikEIZL2yDumllWJT8gw7Y0DMDA7yBz/Art/F ZPkwnoWiPuHb4HCTaeLMDLUE8yvuTki5KxrWznYhxe/iThEmZmLn5RaL4gYcCoUNm5uH suW7iDku9hjcSCHjoPj20D914miL6WzU70eicme1PW6PveigYF97vH1zDbwRXTSQsZyY YfqMJ2BCGgee9cDymOuaE+6Ie29AbySX5rZfVln8lTNVF39tRSpCUfStuRFZCscxmEbr StiQ== X-Gm-Message-State: ALoCoQmejB00BX4rL/DYJkffDfzFNohgggVcmVa4kAs909ovxoBvtgb2+X0IToI3fqo4Ns5bjO32xCR+UJ8mf93XthnlWBTs8GK5keSKD+PYMOo+vQTisUZKZzCKyAjC26AcGx9Z/DcLxiXcpvcK92lG/0QO19pFzgfR/T2DIfSyN+8ahLaTsOP7BIMHWCBPOn0O66fE8FKb5sSv7uolis+yiTQR3C/4Zw== MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr36208119qgo.25.1396389019265; Tue, 01 Apr 2014 14:50:19 -0700 (PDT) Received: by 10.140.25.184 with HTTP; Tue, 1 Apr 2014 14:50:19 -0700 (PDT) In-Reply-To: References: <20140330011513.D6435744AE@topped-with-meat.com> Date: Tue, 01 Apr 2014 21:50:00 -0000 Message-ID: Subject: Re: gold regression vs BFD ld: __ehdr_start From: Cary Coutant To: Roland McGrath Cc: Ian Lance Taylor , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00007.txt.bz2 > I tried it against all the ehdr_start test cases in ld/testsuite. > It dies with an assertion failure on ld-elf/ehdr_start-missing.d and > ld-elf/ehdr_start-weak.d. Those test cases use a linker script with a SECTIONS clause and no PHDRS clause. In this case, gold runs define_standard_symbols before any segments have been created at all. As a result, all the standard symbols that get added are added as constants, and that failed my assert in set_output_segment(). I can relax that assert, but I've got to wonder if we're doing the right thing here with any of the other standard symbols -- it seems to me they'll all get set incorrectly. In ld/testsuite, the ehdr_start_missing.t script attempts to construct a situation where the first load segment cannot contain the headers by setting the text section start address to 0x10000000. That doesn't work! (At least, not in gold.) Gold will happily place the headers at 0x10000000, and place the text section immediately after that. I'm not sure if this is a bug or a feature. I think this is a known difference between the two linkers that has been discussed before. The only way to keep the headers out of the first load segment is to set the text segment at an address that is not a multiple of the page size. For example, if I run with -Ttext=0x1000100, I'll get the expected undefined reference error. Unfortunately, even if the reference is weak, we always get an error. By defining the symbol early, it's overriding the symbol's binding with STB_GLOBAL, so by the time we try to apply the relocation, we've lost track of the weak binding. -cary