Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by krbdev.mit.edu (8.9.3p2) with ESMTP id VAA05724; Thu, 29 Dec 2005 21:31:34 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id CBAC5E0073; Thu, 29 Dec 2005 21:31:31 -0500 (EST) To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #3316] evaluate use of ELF symbol visibility pragmas for smaller code, GOT, PLT References: From: Sam Hartman Date: Thu, 29 Dec 2005 21:31:31 -0500 In-Reply-To: (Ken Raeburn via's message of "Wed, 28 Dec 2005 18:36:06 -0500 (EST)") Message-Id: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1313 >>>>> "Ken" == Ken Raeburn via RT writes: Ken> On Dec 28, 2005, at 18:16, Sam Hartman via RT wrote: >> My personal opinion is that if we can do this in a manner where >> we guarantee that the symbol visibility and export lists do not >> conflict then we should do so. Ken> There are two main types of conflict there. Ken> First, a symbol marked hidden/internal but in the export Ken> list. From a test I did a little while ago, it appears that Ken> it wouldn't show up in the dynamic symbol table. I was Ken> thinking of adding a test program that would walk through the Ken> export list and try calling dlsym on each symbol. Ken> Second, a symbol with default visibility but not in the Ken> export list. This would be okay, it's just likely to be less Ken> efficient. Though for platforms where visibility is Ken> supported but export lists are not (are there any?), it might Ken> be desirable to run nm and examine the output for Ken> unrecognized, defined symbols. O, sorry, I meant to imply that we should set things up so all our symbol properties come from one place. I.E. it is impossible to get it wrong because there is only one place the data lives so it cannot be inconsistent with anything. --Sam