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

[Daniel D. Daugherty]

On 2/17/14 3:08 AM, Staffan Larsen wrote:
> Good that you are looking at it.
>
> My comment was on map-files. The static map files we have today aren’t involved with creating vtable symbols.

Perhaps I'm misunderstanding what you mean here. I agree that the
map-files do not create the vtable symbols, but they are involved
with exporting vtable symols.

There's a hook in the non-windows mapfiles:

$ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/map*
make/bsd/makefiles/mapfile-vers-darwin-debug:                # INSERT 
VTABLE SYMBOLS HERE
make/bsd/makefiles/mapfile-vers-darwin-product:                # INSERT 
VTABLE SYMBOLS HERE
make/bsd/makefiles/mapfile-vers-debug:          # INSERT VTABLE SYMBOLS HERE
make/bsd/makefiles/mapfile-vers-product:                # INSERT VTABLE 
SYMBOLS HERE
make/linux/makefiles/mapfile-vers-debug:                # INSERT VTABLE 
SYMBOLS HERE
make/linux/makefiles/mapfile-vers-product:              # INSERT VTABLE 
SYMBOLS HERE
make/solaris/makefiles/mapfile-vers:                # INSERT VTABLE 
SYMBOLS HERE

and there's logic in the non-Windows Makfiles:

$ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/*.make
make/bsd/makefiles/vm.make:     awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS 
HERE")  \
make/linux/makefiles/vm.make:   awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS 
HERE")  \
make/solaris/makefiles/vm.make:               if ($$0 ~ "INSERT VTABLE 
SYMBOLS HERE") {  \

and they show up in the mapfile generated during the build:

$ grep -c _vtbl_ 
solaris_amd64_compiler2/*/mapfilesolaris_amd64_compiler2/fastdebug/mapfile:3682
solaris_amd64_compiler2/product/mapfile:2596

$ grep _vtbl_ solaris_amd64_compiler2/product/mapfile | head -5
         __1cCIfG__vtbl_;
         __1cCosTSuspendedThreadTaskG__vtbl_;
         __1cDOp2G__vtbl_;
         __1cDPhiG__vtbl_;
         __1cDSetG__vtbl_;

Dan

>
> /Staffan
>
> On 17 feb 2014, at 09:18, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
>
>> 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.