Oracle Solaris is implemented by using a 64-bit kernel and applications that examine or modify the contents of the kernel directly must be converted to 64-bit applications and linked with the 64-bit version of libraries.
Before doing this conversion and cleanup work, you should examine why the application needs to look directly at kernel data structures in the first place. It is possible that in the time since the program was first ported or created; additional interfaces have been made available on the Oracle Solaris platform, to extract the needed data with system calls. The most common APIs are sysinfo(2), kstat(3KSTAT), sysconf(3C), getloadavg(3C), and proc(5). If these interfaces can be used instead of kvm_open(3KVM), you must use them for maximum portability. As a further benefit, most of these APIs are probably faster and might not require the same security privileges needed to access kernel memory.
The 32-bit version of libkvm returns a failure from any attempt to use kvm_open(3KVM) on a 64-bit kernel or crash dump. Similarly, the 64-bit version of libkvm returns failure from any attempt to use kvm_open(3KVM) on a 32-bit kernel crash dump.
Because the kernel is a 64-bit program, applications that open /dev/ksyms to examine the kernel symbol table directly need to be enhanced to understand ELF64 format.
The ambiguity over whether the address argument to kvm_read() or kvm_write() is supposed to be a kernel address or a user address is even worse for 64-bit applications and kernel. All applications using libkvm that are still using kvm_read() and kvm_write() should transition to use the appropriate kvm_read(), kvm_write(), kvm_uread(), and kvm_uwrite() routines. (These routines were first made available in Solaris 2.5.)
Applications that read /dev/kmem or /dev/mem directly can still run, though any attempt they make to interpret data they read from those devices might be wrong; data structure offsets and sizes are almost certainly different between 32-bit and 64-bit kernels.