Allow linker script on executable and hidden symbol

[H. J. Lu]

On Mon, May 02, 2005 at 07:02:41PM -0700, James E Wilson wrote:
> On Sat, 2005-04-30 at 00:18, H. J. Lu wrote:
> > It turns out that 2 patches I submitted:
> > http://sourceware.org/ml/binutils/2005-04/msg00617.html
> > http://sourceware.org/ml/binutils/2005-04/msg00822.html
> 
> The first patch is for turning hidden protected symbols into global
> symbols.  The thread says that this will break function pointer
> comparisons.  This doesn't seem like a good idea.  Nor does it seem
> necessary to fix this particular problem.

When you mark a symbol hidden, it is done on purpose. The only
reasonable way to get a function pointer of a hidden symbol is using
a function call. This is similar to -Bsymbloc. The differences are
you can do it on selective symbols and compiler can take advantage of
it.

> 
> The second patch is for applying a version script to an executable
> instead of a shared library, so that you can globalize a symbol in an
> executable.  This seems harmless enough, and seems sufficient to solve
> the problem.  It is adding a new feature that doesn't seem to conflict
> with any existing ones.  However, we probably need some documentation
> updates.  The docs only talk about using version scripts with shared
> libraries.  What exactly does it mean to apply a version script to an
> executable?  Does specifying a version number in the version script do
> anything?  I don't think it does.  Perhaps all we need is to modify the
> paragraph that starts "Node name can be omited ..." to mention that this
> form can also be used when linking executables.  Should we add some
> checking code here maybe?  I.e. complain if !info->shared and there is a
> version node name?  That might help catch version script mistakes.

I will give it a try.

> 
> This is getting a bit far afield from what I normally review, as there
> is no longer any IA-64 specific parts to this patch, and it is in the
> linker which is the part that I understand the least.  It would be
> useful to have some second opinions here.


Thanks.


H.J.