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
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.