In-Reply-To: <rt-3316-15347.17.2827002497338@krbdev.mit.edu>
References: <rt-3316-15347.17.2827002497338@krbdev.mit.edu>
MIME-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C0EDFB45-D7E0-4BBC-BEB7-FB17C8CA66FE@MIT.EDU>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3316] evaluate use of ELF symbol visibility pragmas for smaller code, GOT, PLT
Date: Wed, 28 Dec 2005 18:35:52 -0500
To: rt-comment@krbdev.mit.edu
RT-Send-Cc: 
Content-Length: 997

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.

There are two main types of conflict there.

First, a symbol marked hidden/internal but in the export list.  From  
a test I did a little while ago, it appears that it wouldn't show up  
in the dynamic symbol table.  I was thinking of adding a test program  
that would walk through the export list and try calling dlsym on each  
symbol.

Second, a symbol with default visibility but not in the export list.   
This would be okay, it's just likely to be less efficient.  Though  
for platforms where visibility is supported but export lists are not  
(are there any?), it might be desirable to run nm and examine the  
output for unrecognized, defined symbols.

> We should also make sure that in cases where features we need are not
> available we do not use them.

Yup.

Ken