Bug 3070 - dwarf_find_proc_info's visiblity does not allow frysk to build if it is used
Summary: dwarf_find_proc_info's visiblity does not allow frysk to build if it is used
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Andrew Cagney
Depends on:
Blocks: 2936 3076
  Show dependency treegraph
Reported: 2006-08-15 18:09 UTC by Adam Jocksch
Modified: 2006-10-06 05:23 UTC (History)
4 users (show)

See Also:
Last reconfirmed:

Patch that uses libunwind-ptrace infrastructure to locate dwarf info in the remote process (3.56 KB, patch)
2006-09-04 03:53 UTC, Alexandre Oliva
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jocksch 2006-08-15 18:09:36 UTC
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
Comment 1 Alexandre Oliva 2006-08-18 08:23:53 UTC
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.
Comment 2 Andrew Cagney 2006-08-28 01:16:00 UTC
Bug in libunwind; which should handle remote dwarf2.
Comment 3 Alexandre Oliva 2006-09-04 03:53:25 UTC
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.
Comment 4 Alexandre Oliva 2006-10-06 05:23:22 UTC
This has been fixed for a couple of weeks.