RFR: 8017234: Hotspot should stop using mapfiles [v2]

Magnus Ihse Bursie ihse at openjdk.org
Thu Feb 22 12:29:54 UTC 2024


On Thu, 22 Feb 2024 12:24:09 GMT, Magnus Ihse Bursie <ihse at 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


More information about the build-dev mailing list