From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19475 invoked by alias); 7 Oct 2014 10:45:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19398 invoked by uid 89); 7 Oct 2014 10:45:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp14.uk.ibm.com Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 07 Oct 2014 10:45:26 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Oct 2014 11:45:21 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 7 Oct 2014 11:45:20 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 7AD971B08051 for ; Tue, 7 Oct 2014 11:46:34 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s97AjJDU56623228 for ; Tue, 7 Oct 2014 10:45:19 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s975hHAd002618 for ; Tue, 7 Oct 2014 01:43:17 -0400 Received: from bl3ahm9f.de.ibm.com (sig-9-79-88-39.de.ibm.com [9.79.88.39]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s975hFU8002511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 01:43:16 -0400 Received: from dvogt by bl3ahm9f.de.ibm.com with local (Exim 4.76) (envelope-from ) id 1XbSGc-0001CG-50; Tue, 07 Oct 2014 12:45:18 +0200 Date: Tue, 07 Oct 2014 10:45:00 -0000 From: Dominik Vogt To: Ian Lance Taylor Cc: gcc-patches , "gofrontend-dev@googlegroups.com" Subject: Re: [gofrontend-dev] [PATCH 5/9] Gccgo port to s390[x] -- part I Message-ID: <20141007104517.GA2739@linux.vnet.ibm.com> Reply-To: vogt@linux.vnet.ibm.com Mail-Followup-To: Ian Lance Taylor , gcc-patches , "gofrontend-dev@googlegroups.com" References: <20140909124446.GA25290@linux.vnet.ibm.com> <20140909125610.GF25290@linux.vnet.ibm.com> <20141006074230.GA19559@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14100710-1948-0000-0000-0000015BECBB X-SW-Source: 2014-10/txt/msg00537.txt.bz2 On Mon, Oct 06, 2014 at 07:29:33AM -0700, Ian Lance Taylor wrote: > On Mon, Oct 6, 2014 at 12:42 AM, Dominik Vogt wrote: > > On s390[x] the symbol value of a section symbol is definitely not > > zero. > > Is true even in an object file? No. > I agree that in an executable a > section symbol will have a non-zero value, but that case doesn't arise > since an executable won't have (non-dynamic) relocations. But I'm > quite surprised that hear that the section symbol would be non-zero in > an object file. I spent a day looking at that issue again, and while it's true that section symbols don't necessarily have a zero value, that is not the problem here. The problem is about how cgo determines the names of functions(?) from an object file. On s390 we need to do an indirect lookup of (non-section-)symbols to find the names, and the symbol value is not zero. The only points in that patch are that on one hand - as far as I know - the Abi does not guarantee that section symbols are either zero or not relocated, even if that may be the case in reality. And on the other hand, if that code is ever modified to handle non-section symbols, it's not obvious that you not only need to remove the test for the symbol type but also modify the calculations below. So, apply the patch or drop it as you like, but in any case, at least a comment in the code would improve maintainability. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany