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

[Dmitry Samersoff]

Staffan,

I'd dived into this problem last week.

SA uses address of vtable (_ZTV* symbols) to calculate base addresses
for couple of internal structures.

i.e. (roughly) it takes vtable address, add offset from vm_structs and
get the data.

Since the time when hotspot build switched to gcc 4.x it doesn't work,
so many of SA command (e.g. jdis) is broken now.

I'm looking for solution.

see
https://bugs.openjdk.java.net/browse/JDK-8034065

-Dmitry


On 2014-02-17 11:50, Staffan Larsen wrote:
> 
> 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
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.