JDK-8247272 : SA ELF file support has never worked for 64-bit causing address to symbol name mapping to fail
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-06-09
  • Updated: 2024-11-13
  • Resolved: 2020-07-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 16
11.0.15Fixed 16 b07Fixed
Related Reports
Relates :  
JDK-8247515 - OSX pc_to_symbol() lookup does not work with core files
Relates :  
JDK-8034065 - GCC 4.3 and later doesn't export vtable symbols any more which seem to be needed by SA
Relates :  
JDK-8247518 - Umbrella bug for tracking PointerFinder related bugs
Relates :  
JDK-8247516 - DSO.closestSymbolToPC() should use dbg.lookup() rather than rely on java ELF file support
Description
There is some java level support in SA for reading ELF files, mainly to get symbolic information. It is located in classes like ELFFileParser.java. It was never ported to 64-bit, and is completely broken on those platforms. It's main use is to convert an arbitrary address into a hotspot symbol, such as a C++ method name or vtable. This is why the "whatis" command is currently not mapping addresses to native symbols, nor is the "mem" command. Note both of these commands currently have been missing since JDK 9 since they rely on SA javascript support, which has been broken since JDK 9 (and is now completely removed). However, I'm in the process of moving these commands into java, and am addressing this lack of 64-bit elf file support while doing that.

Fixing the ELF file support for 64-bit is not too hard. I've made the needed changes and they seem to be working.

One additional thing to point out is that we also have ELF file support in libsaproc. This does work with 64-bit, and is the reason that the underlying support for instantiating java wrappers for hotspot C++ objects still works. That mechanism relies on the native support for looking up the C++ type for a given address. You get to it via LinuxDebugger.lookup(addr). I was somewhat tempted to switch uses of the java ELF support to use this mechanism instead, but since fixing it was pretty easy, and I wasn't sure of other consequences of the removing the java support, I stuck with fixing it instead. Note that switching to using the lookup() support would also mean making lookup() an abstract method of JVMDebugger, which I also was not sure of possible unforeseen consequences.
Comments
OK, approving on the grounds that it is a bugfix for the serviceability agent.
22-02-2022
This one was identified as an interesting potential backport when discussing SA issues/fixes with Chris Plummer.
21-02-2022
Hi Matthias, can you elaborate a bit more why you request this backport? E.g. were you trying to analyze some issue with SA?
18-02-2022
jdk11u fix request I would like to have the fix in 11 because the issue is present there too. The patch applies cleanly.
18-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/833 Date: 2022-02-18 12:44:16 +0000
18-02-2022
URL: https://hg.openjdk.java.net/jdk/jdk/rev/b455665c223e User: cjplummer Date: 2020-07-15 23:57:06 +0000
15-07-2020
I've decided to go with the solution of calling the native ELF support via dbg.lookup(addr), which on OSX will end up calling mach-o symbol lookup support. However, there are bugs there also, which will need to be fixed by JDK-8247515 first. I also still plan on pushing the fixes for the Java level ELF file support since I already have them working and would like to archive the fixes. That will be done under this CR. JDK-8247516 was filed for using the dbg.lookup(addr) mechanism.
12-06-2020
Double sigh. The SA OSX mach-o support only supports looking up a symbol address based on the symbol name (linux supports going both ways), although it looks like for core files it supports address to symbol lookup, although I still need to try that out (it's clearly in the source). So it turns out SA only needs symbol to address looku support in order support vtable lookups when doing wrapper class instantiations. It can first lookup every vtable for every class in VMStructs, and build a reverse lookup table from this. However, for findpc/where support we really need an address to symbol lookup, and it's just not there in our OSX port (except possibly for core files). So for this bug that leaves two solutions for ELF files, both of which I have working. One is to directly fix the existing java ELF file support so it works for 64-bit, and the other is to throw it all out and use the dbg.lookup(addr) support, which works on linux and windows. The latter may have the advantage of also helping with symbol lookups on OSX core files, if that does indeed work. More to come.
11-06-2020
Sigh, was easy to get working for Linux, but turns out we default to treating the binary as ELF on OSX also, and that's not the case. It's mach-o. So the shared code that leads to the ELF support, which is in posix/DSO.java, is broken on OSX because it shouldn't be defaulting to ELF support, and we don't have the equivalent Java level support for mach-o. So now I am inclined to throw away the java ELF code and default to having symbol lookups use the debugger lookup() support instead, for which there are versions for all OSes and binary formats. It just needs to be abstracted better to get to it.
09-06-2020