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

[Dmitry Samersoff]

Dan,

It was my bad - missed two related threads.

We have two problems related to map files:

1. We have hand-written mapfiles and have to manage it manually.

It's better to generate map file automatically or use visibility attributes.

2. Since gcc 4.3.x vtable symbols _ZVT* is not exported ever if they
explicitly appears in map file.

It brakes large part of SA functionality.

-Dmitry


On 2014-02-17 18:26, Daniel D. Daugherty wrote:
> 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.
> 


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