Happens when dealing with transported cores, and the JDK location is different than on the original machine.

The Linux core file contains absolute paths to all loaded libraries, and these paths are used by SA when loading the core file. If the paths don't match, loading the core fails with a message like:

    lookup failed for symbol 'gHotSpotVMTypes' in obj '(null)'

This is where the journey ends for most users. If someone is determined enough, they may find that this error can be worked around by setting the environment variable SA_ALTROOT to the path to the local JDK. However, SA_ALTROOT is then used to load all libraries, including the ELF interpreter, so using SA_ALTROOT results in the following error:

    libsaproc DEBUG: ELF interpreter /lib64/ld-linux-x86-64.so.2
    libsaproc DEBUG: can't open runtime loader

in order to work around this, one needs to copy the ELF interpreter library to the SA_ALTROOT directory.

Now. I think we can make it work out of the box; the location of the Java executable is provided on the command line, and the original location is available in the core file as a NT_FILE note. We could use these 2 paths to rewrite the path to JDK libraries, and open them from the locations where they are available on the debugger machine.

Documentation of the NT_FIL note format: https://github.com/torvalds/linux/blob/master/fs/binfmt_elf.c#L1624