Re: Inline symbols visibility
Re: Inline symbols visibility
- Subject: Re: Inline symbols visibility
- From: Andreas Grosam <email@hidden>
- Date: Fri, 2 Apr 2010 19:10:08 +0200
On Apr 1, 2010, at 11:58 AM, Guillaume Billard wrote:
> Hello,
>
> We're using GCC 4 visibility feature, by compiling our app with -fvisibility=hidden and adding __attribute__((visibility("default"))) as a macro for symbols that need to be exported.
> After reading Apple's guide and the GNU wiki about visibility, I thought that making a class visible made everything inside it visible as well.
> But when compiling one of our libs with -O3, a method is not exported even though the class it belongs to uses the right attribute.
> This method is defined inside the class definition, so I'm guessing that the compiler inlined it and that's why it wasn't exported.
There exists only a symbol of an inline member function in a DSO if there is also an out-of-line copy of this inline member function within the DSO. If there exists an out-of-line copy, then there was at least one reason not to inline the member function, e.g. the function is too large, or there are direct references to the address of the function. The visibility flag however, does not determine whether an inline declared member function will have an out-of-line copy. If there is no out-of-line copy, there is no symbol.
An inline declared member function may be compiled by one ore more translation units (that is, the module which includes the header and inline definition) and the code for the member function will be created eventually for each of this translation unit (resides in an object file). If this member function was always inlined, there exists no symbol in a final DSO. Notice, that even if this member function is from a class defined in a library, the code of the inline member function will exist in the object file created when compiling the corresponding translation unit.
When the member function is not inlined, that is if there is an out-of-line copy, then the flag -fvisibility-inlines-hidden determines if the member function will be visible in this DSO for any other DSO.
Usually you rarely want to have the out-of-line copies of an inline declared member function be visible, otherwise you could declare the function out-of-line explicitly. Hence, -fvisibility-inlines-hidden is ON by default, which is a good thing.
Note also, that the existence of an out-of-line copy, does not mean that there are no occurrences of inlined functions!
You should be carefully, though with static declared member variables which may be accessed in inline member functions. The static member variable shall be visible, and all copies of an inline member function shall access this single instance. Usually, the compiler and linker takes care about all of this - but not always (see one of my previous post).
> I found this thread where it seems that the same behavior occurred:
> http://lists.apple.com/archives/xcode-users/2005/Jul/msg00609.html.
>
> Adding the "default" visibility attribute to the inline method solved the problem.
> If I'm not mistaken, the compiler gets to decide wether to inline methods or not, even when they're defined out of their class definition.
> It appears that it can inline methods for classes that use __attribute__((visibility("default"))), but I don't know if it can do the same for out-of-class methods. I'm hoping not.
> I'd like to know if adding the attribute to a method of a visible class whenever it doesn't get exported is the right approach.
Actually, it will be *exported* , the function is in your header. Unless its declared private in the class, clients have "access" to it. Do you mismatch interfaces and visibility?
> It kind of turns the granularity of the visibility from class to method.
> The only other solution that I can think of is to define the method out of the class but as I said I don't know if it's supposed to work all the time, and in my case it's not a practical thing to do.
I don't think visibility is a problem here. When a client includes the headers, it gets access to the class according the accessibility rules, and of course can call the inlined member function if it is accessible for the client. "visibility" is an orthogonal problem to this, and in fact is not a language thing at all - its merely an implementation artifact.
Andreas
>
> Thanks!
>
>
> Guillaume
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden