acl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Acl-devel] [RFC] Add attribute visibility("default") to API functio


From: Yury Gribov
Subject: Re: [Acl-devel] [RFC] Add attribute visibility("default") to API functions
Date: Wed, 17 Feb 2016 11:33:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 02/17/2016 07:24 AM, Mike Frysinger wrote:
On 17 Feb 2016 00:57, Andreas Grünbacher wrote:
2016-02-16 21:50 GMT+01:00 Mike Frysinger <address@hidden>:
On 16 Feb 2016 23:18, Yury Usishchev wrote:
Ok, the patch is attached.

i'm fine with this (although i haven't tested it yet).
let's see what Andreas has to say.

This patch looks simple enough, but I really don't want to have the
ACL_API_EXPORT define in the public headers: it doesn't add anything
for users, it just makes the header messier to read. An ACL_API_EXPORT
or similar macro can just as well be added where each function is
defined, with the same net result.

Still many packages already use this approach (just grep your /usr/include for 'define.*EXPORT.*visibility'.

unfortunately, it cannot.  the visibility has to be set on the prototype
so that when other functions see it, gcc knows how to call it and what
optimizations to use.

We need to distinguish where the call is done from.

My understanding is that visibility annotations are indeed useless when calling external library function because linker will generate a PLT call regardless. But they are very important for intra-library calls because compiler will generate direct call and also optimize much more agressively (especially under LTO).

The real problem here is that the same library header is typically used both by external users and by library internals. AFAIK maintainers typically annotate it and users have to live with one more (useless) public macro.

-mike






reply via email to

[Prev in Thread] Current Thread [Next in Thread]