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

[Staffan Larsen]

On 17 feb 2014, at 03:15, David Holmes <david.holmes at oracle.com> wrote:

> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote:
>> 
>> On 2014-02-05 19:09, Volker Simonis wrote:
>>> If there are any more/other comments on this topic I'll be highly
>>> interested.
>> 
>> You can count on me having lots of opinion on build issues. ;-)
>> 
>> I'd like to get rid of the hard-coded map files completely, both in
>> hotspot and jdk. This can be done without loss of functionality. How?
>> Because we can generate them on the fly at build time, using information
>> provided by the source code.
> 
> Does that account for the dynamically generated symbols used by the SA?

I think the symbols SA care about are all already declared with JNIEXPORT.

/Staffan

> 
> David
> 
>> Note that the exported functions are prefixed by the macro JNIEXPORT. We
>> can locate all functions that have this prefix and write them to a map
>> file. This can be done, and was indeed the way we solved things back in
>> the JRockit JVM. The technique we used there was to grep for "JNIEXPORT"
>> and check for a symbol name (as provided by nm). We had rules requiring
>> that JNIEXPORT was to be written on the same line as the function name,
>> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT"
>> and then cross-reference for names extracted by nm. Not exactly a formal
>> semantic parsing, but it was efficient and worked very well. I believe
>> we can do something very similar for hotspot and jdk.
>> 
>> Then again, if we could get rid of maps completely, by using visibility
>> and not linking statically with the standard libs, that would be even
>> better. :-)
>> 
>> /Magnus