If libunwind/include/dwarf.h is included and dwarf_find_proc_info is used the linker complains when building fryski that it is attempting to link to a hidden symbol inside a .so. If the UNW_REMOTE_ONLY configure flag is set then the visibility of the method is removed altogether resulting in an unsatisfied link error.
dwarf_find_proc_info() is an internal function, that is only supposed to be used in local settings anyway. The entire implementation assumes local memory access is possible. A full rewrite would be needed in order to use the same logic but remote memory addresses. If we go that route, it might make sense to simply replace the current implementation of frysk.rt.StackCallbacks.findProcInfo with the appropriate logic. libunwind actually has built-in support for find_proc_info in remote settings, but it doesn't use the dwarf-specific LSB-compliant logic from libunwind/src/dwarf/Gfind_proc_info-lsb.c, but rather some simpler logic in libunwind/src/mi/Gremote-dyn.c, which is implicitly called if you call the standard entry point unw_get_proc_info_by_ip(). The only catch here is that unw_get_proc_info_by_ip() doesn't accept a needInfo argument, and it passes that down as false to the actual find_proc_info implementation, so we'd have to somehow implement that as well. Oh, and unw_get_proc_info_by_ip() will call cb->find_proc_info, so if we call that from our own accessor callback, we'll get infinite mutual recursion. /me feels that we might be better off reimplementing the LSB logic in Java with correct remote semantics, as painful as that might seem, if we are to use the LSB logic. If that's not the point of using dwarf_find_proc_info(), I wonder what is. Some guidance will be needed.
Bug in libunwind; which should handle remote dwarf2.
Created attachment 1275 [details] Patch that uses libunwind-ptrace infrastructure to locate dwarf info in the remote process As explained before, libunwind is perfectly capable of dealing with remote dwarf info, it's just that one particular function that's not meant to be used in these cases. This patch uses the existing infrastructure in libunwind-ptrace to locate unwind and dwarf info. It's worth noting that, since we still use frysk's callbacks to access memory and registers from the remote process, even the few libunwind-ptrace function we use still go through our callbacks to interact with the remote process.
This has been fixed for a couple of weeks.