From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27503 invoked by alias); 1 Apr 2014 22:50:40 -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 27492 invoked by uid 89); 1 Apr 2014 22:50:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 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-ie0-f179.google.com Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 01 Apr 2014 22:50:33 +0000 Received: by mail-ie0-f179.google.com with SMTP id lx4so9974483iec.38 for ; Tue, 01 Apr 2014 15:50:31 -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:from:date :message-id:subject:to:cc:content-type; bh=v4kBzZ7oj1wXqScJRwmoGoJMd+y0LAOj+RD+rnJ/jsY=; b=LKZmr6ou/btEBQ+8eGczAldnAFFdeTJz0GZSOZ/qHWJltL9zBODPLlK1jl3mPPXv1X RveFtTzOakizRy6C1+45vMouPMjPezNZq8NllyLPu1hF/iYYb65JQPFKSBlZXTAp+SoX GnMF+4+UGkW/umQHigDyLr5pLJv643UEy/dmdLGPIsB5GFgD+sf+58ENP6dTtuzWCGQA UikpA2J6+5MhbDVd2tHBnuXmzosRlNaCu9XxdnVhZwI97q6thwc6f3Ctlz+qwoTZhki7 SudwjPOfjb6OfLCdbC5qhcJG/oUERvV4wy41vQXe0cwtOok1/Xh11rK8YVB60W3R2L6z 5dKA== X-Gm-Message-State: ALoCoQluo9jZWl8vM5HW6mW12sPSWA/HmeGtRtl4mjVPCMpiJ83m1+XOKqGNdZDodfHn9XpWHak4i0jVvncC74AIzli065838vZ2obe9Xf+H8s7QpkY8MbuFlCfpGnNpdRVLOTXJk7vJqcr4nFfc2MLg46T0IeX89m7ACHWg+TeEgC6LMYjutp9UOfzqWBwmdpEEz2r2jlk0YgJTRMJCQahwAdxy1ub4rA== X-Received: by 10.50.154.66 with SMTP id vm2mr5564940igb.4.1396392631233; Tue, 01 Apr 2014 15:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.3 with HTTP; Tue, 1 Apr 2014 15:50:11 -0700 (PDT) In-Reply-To: References: <20140330011513.D6435744AE@topped-with-meat.com> From: Roland McGrath Date: Tue, 01 Apr 2014 22:50:00 -0000 Message-ID: Subject: Re: gold regression vs BFD ld: __ehdr_start To: Cary Coutant Cc: Ian Lance Taylor , Binutils Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-04/txt/msg00010.txt.bz2 On Tue, Apr 1, 2014 at 2:50 PM, Cary Coutant wrote: > 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. Certainly worth worrying about. I've definitely seen cases in the past where gold did not implement linker script semantics properly. (https://sourceware.org/bugzilla/show_bug.cgi?id=13163 comes to mind.) > 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. It's a bug. The linker script said where the .text section should be, and you placed the .text section someplace else. I was not aware of this particular "difference" before. It feels similar to two issues I am aware of: * gold's -Ttext=x means -Ttext-segment=x, whereas -Ttext=x is supposed to mean --section-start=.text=x and that (like the linker script case above) does not give the linker license to actually place .text at x+SIZEOF_HEADERS. * https://sourceware.org/bugzilla/show_bug.cgi?id=13163c#5 points out out a case where assignment of . to a constant means something different in gold (I think it acts as relative to some section rather than absolute, but I no longer recall the exact details). > 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. That's a fine thing to test, too. For gold it certainly makes sense to exercise cases without linker scripts, since the internal logic is so different for with vs without. But getting that case right is not really sufficient to declare __ehdr_start properly supported. > 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. That's certainly a bug. I don't know how to address it. I had hoped that the 'only_if_ref' flag would have the semantics that if there was another definition, none of the symbol details in the call would modify it. But I can imagine why it's not like that. The -shared case working right without trying to generate a dynamic reloc is sufficient for gold to pass glibc's configure check for __ehdr_start support and for __ehdr_start as used in ld.so to be correct. So perhaps what you've got now is enough better to be worth putting in. The other corner cases are of some interest to me, but I don't think anything I'm actually planning to do will wind up exercising them. Thanks, Roland