RFC: Considering expanding the inline functions of the frames in hs_err file

[高丹(昭珏)]

Hi everyone!
I noticed the same problem with JDK-8305005[1] that the function name sometimes not match with the source line information in hs_err file. As Dean Long said, the code that gets the function name is using dladdr(), so it gets the outer-most frame. The code that gets the file name and line number is using ElfDecoder-->ElfFile-->DwarfFile and gets the inner-most frame. I think the problem can be solved by expanding the inline functions of each frame. 
V [libjvm.so+0x967d21] JNI_CreateJavaVM+0x51 (jni.cpp:3571)
For example, as above, jni.cpp:3571 is in JNI_CreateJavaVM_inner, however, because of the inlining of JNI_CreateJavaVM_inner, dladdr() can only get the outer-most frame JNI_CreateJavaVM. By expanding the inline functions of the frame, we can get the following frames:
V [libjvm.so+0x967d21] JNI_CreateJavaVM_inner(jni.cpp:3571)
JNI_CreateJavaVM(jni.cpp:3657)
Thus the function name can be consistent with source line information. But so far I don't know how to get the offset of outer frame.
I'm doing this work by pyelftools. Firstly we can obtain the compile unit by the given offset. And then by recursively traversing the children of top debugging information entry of the compile unit, we can obtain the call frames of inline functions and get the source file and line number by 'DW_AT_call_file' and 'DW_AT_call_line'. I'm considering implementing this feature on the fundamental of JDK-8242181, as I believe it could provide convenience for many users. 
I wonder what you think about this issue. I'm willing to fix it if it is worthy. Any ideas are appreciated. 
Best Regards.
[1]https://bugs.openjdk.org/browse/JDK-8305005 <https://bugs.openjdk.org/browse/JDK-8305005 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20230420/a74ec8db/attachment-0001.htm>