Hotspot symbol visibility - surprising news!

[Magnus Ihse Bursie]

On 2024-02-19 17:43, Daniel Jeliński wrote:

> Hi Magnus,
>
> The "massive generated mapfile" is used on Windows. As you noticed, on
> Linux symbols are exported if they are both JNIEXPORT and listed in
> the mapfile. On Windows, the symbols are exported if they are either
> JNIEXPORT or listed in the mapfile. The Windows symbolicator needs to
> see the vftables to tell apart different object types, and these
> tables are only made available in the produced binaries through the
> mapfile. The Windows mapfile exports the vftables of every virtual
> class in libjvm, which is much more than the symbolicator actually
> needs, but that's probably a separate topic.
>
> The symbolicator on Linux does not need the mapfile.
>
> The assembly functions are correctly labelled with .globl; if we
> remove these declarations or change them to local, the code won't
> link. The right solution here is to also label them as .hidden, for
> example using this script:
>
>       sed -i -n 'p;s/\.globa\?l/.hidden/p' src/hotspot/os_cpu/*/*.S
>
> The symbols from the standard libraries are not exported by any of our
> binaries. Libjvm removes them via the use of mapfile, and all other
> libraries are linked with  -Wl,--exclude-libs,ALL; if you choose to
> remove the mapfile from libjvm, you'll need to add that parameter.

Thanks Daniel. It is clear that you have studied this in detail. I 
rediscovered most of what you said here on my journey to fix 
JDK-8017234. :-)

I guess that after the mapfile removal, it would make sense to see if we 
can simplify the process for SA on Windows. Maybe it is possible to 
steal a page from the Linux book and look into the .DLL file directly. 
And also see if there is a way to get the macOS symbolicator to work 
with core dumps, and not only live processes. This is apparently not 
working.

/Magnus