[Bug other/15000] Support setting the default symbol visibility for ELF

["s_gccbugzilla at nedprod dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-19 02:36 -------
Well, I shake my head sometimes. I tried suggesting this enhancement before and 
was rather forcibly told it was too similar to PR 9283 and please go post there.

In the end, I don't give a toss how this is done, who gets the credit or 
anything else. I simply want the feature added in a timely fashion. I'm glad 
that people who were rubbishing the mere idea a few months ago have changed 
their tune. But this so called process is making me shake my head :(

> I'm confused by your local_p change, actually.  I don't see how it changes the
> current behavior at all... it appears to already be setting local_p=true for
> decls with DECL_VISIBILITY != VISIBILITY_DEFAULT.

No that was the behaviour before I altered it - now factors such as whether it 
was declared static, is a weak symbol etc. take precedence over visibility 
specification. This is required for correct operation.

> If you treat a symbol in an external DSO as hidden visibility, the compiler 
will
> not generate a PLT jump for that function call, and the linker will be forced 
to
> generate a text section relocation.  I'm pretty sure that's bad (prevents
> sharing of the text section across processes).  So I really think we need to
> provide an easy way for the user to ensure that declarations of functions in
> external DSOs are treated as default visibility.

They already are. If a symbol is merely declared and not defined (ie; 
TREE_PUBLIC() is true or DECL_EXTERNAL() is true), it is always non-local. I 
examined the assembler output during testing to ensure the various combinations 
were correct. However, I am not an expert with ELF nor GCC, so I may have made a 
mistake causing loss of efficiency (however I can guarantee the Boost.Python 
library as well as my own work far better and correctly with this patch enabled)
.

> Implementing -fvisibility-default _efficiently_ may be difficult.  We don't 
want
> to have to generate the assembler name for each decl we encounter to check if
> it's one with visibility overridden.  It would be better if we could generate 
a
> lookup table from the symbol file which could be compared against the decl
> without any additional string manipulation or allocations.  I think for C that
> just means comparing the DECL_NAMEs; for C++ the DECL_NAME doesn't uniquely
> identify the resulting symbol so we'd need to extract all of the relevant info
> from the mangled symbol name.

That is your baby. I don't think it's necessary right now as the GNU linker 
provides version scripts which are good enough for the time being.

> One idea that _doesn't_ require implementing -fvisibility-default= is to
> generate and use a precompiled header that brings in all of the declarations 
for
> those functions and compile the header without -fvisibility=hidden.  Or, along
> the same lines, implement some construct you can wrap #includes with to say 
that
> the header declares functions that have default visibility.

Again, we're getting off track here. Right now anyone trying to use a lot of 
template metaprogramming with GCC is really suffering because of GCC exporting 
far too many unnecessary symbols. Ask anyone using the Boost library regularly - 
hell, go ask Dave Abrahams himself.

I am no GCC hacker nor have any wish to become one - when this is integrated you 
won't be seeing more of me. However when the tools are not cutting the mustard 
you can either whine or do something about it.

The patch I have submitted fixes these woes right here right now. Other issues 
are important but they are other issues which can be solved at another time. 
What we need for this enhancement now is for someone expert with GCC internals 
to review the patch and if it's good to apply it to CVS head as soon as 
possible. Other related features and enhancements can come later.

(Sorry if I am being too brusque, but I'm getting the distinct feeling that the 
merry-go-round is rotating more than it should)

Cheers,
Niall


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15000