Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))

[Jeremy Manson]

Also, don't you statically link libstdc++ into Hotspot?  It would break
many, many things if the symbols from that were exported from Hotspot
(pretty much anything with native code written in C++).

Jeremy


On Tue, Feb 4, 2014 at 4:51 PM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Volker,
>
>
> On 5/02/2014 2:18 AM, Volker Simonis wrote:
>
>> I know this is an old topic and actually I was involved myself in some
>> of these discussions. Nevertheless, the topic regularly pops up again
>> and every time this happens and I take a deeper look at the topic I
>> have the feeling I still haven’t completely understood it.
>>
>> Current state:
>>
>> On Linux, we are currently compiling the HotSpot with the
>> '-fvisibility=hidden' flag which effectively hides all symbols except
>> the ones which are explicitely declared to have default visibility
>> (with the macro JNIEXPORT which expands to
>> __attribute__((visibility("default")))).
>>
>> This was introduced by "6588413: Use -fvisibility=hidden for gcc
>> compiles" [1] in HS 21 and it is potentially a good change because it
>> hides all symbols by default and it enables certain compiler
>> optimizations on some platforms (see "How To Write Shared Libraries"
>> [2]).
>>
>> However, independently of this change, we still use export maps (i.e.
>> --version-script=mapfile_reorder) in addition to setting the explicit
>> symbol visibility. While [2] recommends this as good practice, I don't
>> see the real benefit of having both -
>> -fvisibility=hidden/__attribute__((visibility("default"))) and export
>> maps except if we were maintaining a versioned ABI. But as far as I
>> can tell, that's not the case for HotSpot.
>>
>> So finally my question: is there any real reason (except the fact that
>> "we always did it that way") why we would still need to use export
>> maps on Linux where symbol hiding is done with
>> -fvisibility=hidden/__attribute__((visibility("default"))) anyway?
>> Dropping the maps would make the maintenance of exported symbols
>> easier as we wouldn't have to keep the export map files and the
>> JNIEXPORT functions in sync.
>>
>
> From past discussions isn't this because we need the map files to expose
> dynamically generated symbols? (And so we must then also add the other
> visible symbols.) Does that make the visibility attributes redundant? I'm
> not sure, but they serve as a clear statement of intent anyway.
>
> David
>
>
>  Thank you and best regards,
>> Volker
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6588413
>> [2] http://www.akkadia.org/drepper/dsohowto.pdf
>>
>>