From owner-svn-src-head@freebsd.org Tue Jul 19 21:57:32 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BBC6B9E431; Tue, 19 Jul 2016 21:57:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E220C15BA; Tue, 19 Jul 2016 21:57:31 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 448E6358C62; Tue, 19 Jul 2016 23:57:28 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 2906828494; Tue, 19 Jul 2016 23:57:28 +0200 (CEST) Date: Tue, 19 Jul 2016 23:57:28 +0200 From: Jilles Tjoelker To: Ed Schouten Cc: "Pedro F. Giffuni" , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r303046 - head/lib/libc/locale Message-ID: <20160719215727.GA45133@stack.nl> References: <201607192022.u6JKMDJD051361@repo.freebsd.org> 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-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:57:32 -0000 On Tue, Jul 19, 2016 at 10:46:36PM +0200, Ed Schouten wrote: > 2016-07-19 22:22 GMT+02:00 Pedro F. Giffuni : > > Author: pfg > > Date: Tue Jul 19 20:22:13 2016 > > New Revision: 303046 > > URL: https://svnweb.freebsd.org/changeset/base/303046 > > Log: > > libc: tag the Rune initialization function prototypes visibility > > as hidden. > How does this interact with symbol versioning/mapping? Wouldn't our C > library's symbol map already make these symbols hidden without any > explicit annotation? Trying to export (using a version script) a symbol with hidden visibility attribute is an error, but GNU ld might accept it and fix it up using text relocations or by not exporting the symbol. Although both version scripts and visibility attributes can be used to prevent exporting symbols, the goals are different. The goal of version scripts is to enforce that no symbol is exported that is not in the version script. The goal of visibility attributes is to optimize performance and code size. For example, on i386, a function without visibility attributes that is not exported is called directly but still has %ebx set up for the PLT entry. This not only adds extra instructions and stack usage but also prevents tail calls (clang called the GOT entry indirectly for a while to allow tail calls but this was removed because some code depended on lazy resolution which requires PLT entries). -- Jilles Tjoelker