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
