SA ELF file support has never worked for 64-bit causing address to symbol name mapping to fail

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.