Symbol visibility question

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Symbol visibility question

Jeff Law

Per Roland's suggestion here:

http://sourceware.org/ml/libc-alpha/2012-06/msg00207.html

I need to create a trivial little function that svc_{tcp,udp,unix} can
use for failures.  Let's call it __svc_accept_failed.

That function needs to be visible to the svc_{tcp,udp,unix}.c files, but
must not be visible outside glibc or sunrpc.

Unfortunately, I have found any glibc internals documentation on how to
do this.  I see various libc_hidden_proto, libc_hidden_def macros, but
no documentation on how to use them.

I'd like to get this wrapped up, so any advice/pointers would certainly
be appreciated.

jeff
Reply | Threaded
Open this post in threaded view
|

Re: Symbol visibility question

Jakub Jelinek
On Mon, Nov 05, 2012 at 02:20:26PM -0700, Jeff Law wrote:
> Per Roland's suggestion here:
>
> http://sourceware.org/ml/libc-alpha/2012-06/msg00207.html
>
> I need to create a trivial little function that svc_{tcp,udp,unix}
> can use for failures.  Let's call it __svc_accept_failed.
>
> That function needs to be visible to the svc_{tcp,udp,unix}.c files,
> but must not be visible outside glibc or sunrpc.

If it is only for use within a single library (say libc.so.6), and
you don't need to export it, then just put attribute_hidden to its
prototype.

*hidden_proto/*hidden_def/*hidden_ver macros are for the case where you
want some symbol to act as improved protected visibility (normal protected
visibility is expensive, because of function pointer comparison guarantees).
Functions with *hidden_proto macro used after the prototype and *hidden_def
(resp. *hidden_ver after the definition) are both exported and have a hidden
alias, where uses within the same library are bound to the hidden alias.

If you need a function defined in one library used from another library, but
don't want to make it a public API, just use GLIBC_PRIVATE symbol version
for it.

        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: Symbol visibility question

Jeff Law
On 11/05/2012 02:37 PM, Jakub Jelinek wrote:
> If it is only for use within a single library (say libc.so.6), and
> you don't need to export it, then just put attribute_hidden to its
> prototype.
Unfotunately, the rpc bits end up in librpc.a otherwise this would be
perfect.

>
> If you need a function defined in one library used from another library, but
> don't want to make it a public API, just use GLIBC_PRIVATE symbol version
This is probably what I need.  Presumably it'll do the right thing for
bits that also show up in a static library.  I'll poke at and see what I
get.

jeff

Reply | Threaded
Open this post in threaded view
|

Re: Symbol visibility question

Andreas Schwab-2
In reply to this post by Jeff Law
Jeff Law <[hidden email]> writes:

> I need to create a trivial little function that svc_{tcp,udp,unix} can use
> for failures.  Let's call it __svc_accept_failed.
>
> That function needs to be visible to the svc_{tcp,udp,unix}.c files, but
> must not be visible outside glibc or sunrpc.

Since it's just an internal function no visibility settings are needed.
It needs to start with __ to be clean for static linking, but that's
all.  (See __internal_statvfs for an existing example.)

> Unfortunately, I have found any glibc internals documentation on how to do
> this.  I see various libc_hidden_proto, libc_hidden_def macros, but no
> documentation on how to use them.

Those macro are used to add internal aliases to publicly visible
symbols, which is not relevant here.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Symbol visibility question

Florian Weimer-5
In reply to this post by Jakub Jelinek
On 11/05/2012 10:37 PM, Jakub Jelinek wrote:

> If you need a function defined in one library used from another library, but
> don't want to make it a public API, just use GLIBC_PRIVATE symbol version
> for it.

I tried to do that for the internal alias for secure_getenv, but making
that GLIBC_PRIVATE broke dynamic linking.  Are you sure that this works?
  If yes, how?

--
Florian Weimer / Red Hat Product Security Team
Reply | Threaded
Open this post in threaded view
|

Re: Symbol visibility question

Mike Frysinger
In reply to this post by Jeff Law
On Monday 05 November 2012 16:20:26 Jeff Law wrote:
> Unfortunately, I have found any glibc internals documentation on how to
> do this.  I see various libc_hidden_proto, libc_hidden_def macros, but
> no documentation on how to use them.

look at the big comment block in include/libc-symbols.h
-mike

signature.asc (853 bytes) Download Attachment