This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: On which platforms is -fvisibility supported?


Mike Stump wrote:

> On Friday, September 16, 2005, at 10:19  AM, Jonathan Turkanis wrote:
>
>> > I think I can give you an answer which is completely correct and yet
>> > completely useless:  -fvisibility=default is supported on every platform.
>>
>> Thank you -- it's not completely useless.


> It is. > >> I don't want to recommend that users supply -fvisibility=default


> Telling users to supply that flag is useless. It is the default.



It's advertised as the default, but the threads I cited in my last post suggest that in some cases specifying -fvisibility=default produces different results that not specifying any default visibility option, regardless of what the spec says (see below).


> Conceptually, you would want to tell them to not use -fvisibility=hidden.
>
>>  if it will result in an 'unrecognized option' error on some platforms.


>> I sense a joke lurking here.



> We are confounded as to why you would want to tell a users to specify a flag that is the default. After reading to the end of your email, I now understand your question better.



I didn't mention recommending -fvisibility=default until *after* you made the remark to which I was responding.


>> > As Mike says,
>>
>> >> If you tell us what the real question is, maybe we can answer that one.
>>
>> To me, that sounds like an insult


> No, we just have enough experience and knowledge, and we actually do want to help you, but we know enough to know you are hiding the real question from us,



Give me a break! What am I trying to hide? Not that I'm writing a book. I've posted dozens of messages to various newsgroups in the course of my research, and I've mentioned the fact that I was writing a book whenever it was relevant ... or when people seem to be ignoring my questions.


What's really going on is that you seem to have assumed I wasn't really asking
what I plainly was asking. Below you actually give a pretty good answer to my
original question.

> and we know that you need the real answer, but we can't give it to you, since we don't have the question.


>> : why do you think I wouldn't ask the "real" question?



> Experience.



I'm tempted to ask "in what?", but I think I don't really want to know.


>> The docs for -fvisibility say: "Set the default ELF image symbol visibility to the specified option —- all symbols will be marked with this unless overridden within the code...."
>
>
>
> You can read this without the word ELF and is looses nothing, in fact, it would be more accurate.



Okay. I'll try ignoring words here and there and see if improves the quality of the documentation. My guess is it can't hurt.


>> So it seems a fair question to ask where -fvisibility is supported. An answer that isn't "completely useless" would be appreciated.
>
>
>
> M-x grep VISIBILITY tells you the answer.



What are you grepping?


> The answer, is precisely on darwin, and all platforms whose in tree gas assembler is elf whose version is 2.13 and above or if the assembler accepts:
>
> .hidden foo
>
> without returning a non-zero return code from the assembler and the linker is 2.13 and above if in tree, otherwise as long as the linker isn't older than 2002-04-04 or people mussed up the version string of the linker or is 2.12.0 or older we suppose symbol visibility.
>
> Now, did that precisely answer your question?
>
> Compare that with, every interesting platform now supports visibility default/hidden.
>
>> I'm trying to decide what recommendations to make with repect to -fvisibility for a forthcoming O'Reilly C++ book.



> Gosh, now we have a hint at the real question.



Now that you have a hint, tell me what it is.


> I suspect the answer is,
> go ahead and use it


>> At first it looked like a nice way to enable Windows-style exporting of symbols from dynamic libraries on some UNIX/Linux platforms. Now it appears that there may be some serious problems with it, at least as currently implemented. See e.g., http://article.gmane.org/gmane.comp.lib.boost.build/10072 and http://article.gmane.org/gmane.comp.lib.boost.build/10110. Those threads were also the first indication I had that -fvisibility was supported on some non-ELF platforms.
>>
>> I don't have time to verify the assertions made in that thread -- the book went into production in August -- but I trust the author and he seems to have conducted some careful experiments. I'm now inclined just to say that the option, together with the attribute, offered the possibility of Windows-style exporting on some (unspecified) platforms, but that initial implementation is buggy; -fvisibility=default should be specified everywhere, until further notice.
>
>
> Ah, now we can start getting to the meat of the question.
>
> Buggy?



Aha! Now I've got your attention.


> I think I might disagree with that assessment if you are referring to the inability to catch hidden types across the hidden boundary.
>
> Anyway, the real issue boils down to some rather simple concepts. Suppose someone has:
>
> class A {
> };
>
> in one part of their program and:
>
> class A {
> };
>
> in another part of their program. The question is, are they the same? The answer in non-shared library, non-dlopen(), trivial systems, yes. This is visibility default. When people want them to be different, then one erects a fence around one or the other, to prevent them from being the same. visibility hidden, in any of its forms, does that.
>
> The problems the boost people saw were, they wanted an A, that was across the fence to be the same as the other A on the near side of the fence, this is illogical, I might claim, and does not indicate a buggy compiler.



But the example discussed there used no visibility attributes and no -fvisibility options. The problem was an unrequested fence, to use your term. The solution was to supply -fvisibility=default, which you say should never be necessary by itself.

> For you to defend it as a buggy compiler, you'd have to explain by what mechanism you want to mark the two As as being separate. My claim would be that visibility hidden is exactly that mechanism.


The two A's should be the same unless requested otherwise, no?


> Now, if you are asking how to mark the types as default when -fvisibility=hidden is used, gosh, could have sworn there was a way to do it, but someone seems to have broken every incantation I tried. :-( That to me seems to be a bug.
>
> __attribute__ ((visbility("default"))) class A {
> virtual void foo();
> };
>
> A a;
>
> void A::foo() {
> }
>
> and
>
> class __attribute__ ((visbility("default"))) A {
> virtual void foo();
> };
>
> A a;
>
> void A::foo() {
> }
>
> seem like they both should work and when -fvisibility=hidden is used, it should cause the rtti information/vtable information and so on to not be hidden.
>
> Do you know of off hand where Microsoft puts the magic string to export the class?



No.


> Do they even have a concept of not exporting the class?


Not exporting is the default, isn't it?


--
Jonathan Turkanis
www.kangaroologic.com





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]