On Thu, 22 Feb 2024 12:24:09 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, >> so I think gdb did resolve a local symbol (which cannot be found by callling >> dlsym, but can be found in the binary symboltable). >> On Windows the debug.cpp symbols just weren't in the binary at all, then >> with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we >> generate also. >> >> So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp >> symbols into the binary. >> This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in >> the binary. >> >> But I will go check this... > >> they were absent from .dynsym but available in .symtab as bind: local, >> visibility: default. Now they are completely gone. > > I don't think that statement is correct. Or else my understanding about > symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` > (which shows `.dynsym`) are identical for the libjvm.so before and after the > patch wrt to the JNIEXPORTed debug.cpp functions. > > Was this a statement of your understanding of the situation, or could you > spot an actual difference? If it is the latter, please let me know how I can > view this difference. Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499167151
