Hi Magnus, For hotspot symbols that need to be exported, when statically linking the launcher executable using libjvm.a, we use lld's `-Wl,--export-dynamic-symbol-list=` option. Those exported symbols can be used outside the VM code, e.g. in agent. Our friend(s) in c++ compiler/toolchain added the support for --export-dynamic-symbol-list, https://reviews.llvm.org/D107317. -Wl,--dynamic-list with gcc provides similar support.
Best, Jiangli On Wed, Feb 14, 2024 at 2:06 AM Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > > I am currently pursuing improved build functionality for static > libraries. One of the issues with static libraries are name collisions, > which led me back to an old discussion about which symbols are exported > from Hotspot, and how this is achieved. A long discussion is available > in JDK-8017234 [1], which was created in 2013 and has been on the back > burner ever since, coming back to life every now and then. > > There are basically two different problems here. They are both distinct > and interrelated, and we likely need to solve both in tandem. > > The first problem is how Hotspot should say which symbols (functions) > that should be exported from libjvm.so. The historical, and still used, > system is to have a mapfile. In the "new" (not so new anymore) build > system, this was simplified to a list of function names in > make/data/hotspot-symbols, from which a mapfile is built. > > This is in contrast with how all other libraries in the JDK are built, > and also with modern best practices. A better approach would be to > annotate the functions that should be exported in the source code. In > fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but > this is currently not used in the compilation of Hotspot. > > The second problem is that in addition to these explicitly exported > functions, we also export basically all other functions as well in > Hotspot. (So currently we could basically just forgo this complicated > machinery and just export everything by default...) > > The reason for this seem somewhat unclear. The specifics are probably > forever lost in the mists of time past, but the essential point is that > these symbols are needed for SA to do it's job. > > So what we do is that we list all symbols in hotspot after compiling > (but before linking), and selects some (most, I think) of them using > regexp patterns, and add these to the mapfile. > > As long as we're doing this, we cannot stop using a mapfile, and we're > stuck from progressing on point 1. > > My takeaway from the discussions is that we are most likely exporting a > way too broad set of symbols to SA. It seems likely that this set can be > drastically cut down. Actually getting an understanding of exactly which > symbols SA need seem like a very good first step. > > So, is this a journey anyone would be interested in embarkering on? I > will help as much as I can from a build PoV, but I have no clue > whatsoever about what SA needs. > > /Magnus > > [1] https://bugs.openjdk.org/browse/JDK-8017234 >
