[Bug dyninst/15052] externalvar.exp fails with dyninst

["jistone at redhat dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15052

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> 2013-01-23 00:42:23 UTC ---
(In reply to comment #0)
> Commit 421edbd added dyninst support to the
> testsuite/systemtap.base/externalvar.exp testcase. Every dyninst test fails,
> with compilation errors:
[...]
> It looks like there is some kernel code sneaking in there - references to
> "current", the task_finder, etc. It also looks _stp_umodule_relocate() may need
> a dyninst version.

This is coming from dwflpp::emit_address, for any address that requires
relocation.  That will be true mostly for global $var or @var("name") accesses.
 We should probably add a sanity check so enable_task_finder() is rejected in
dyninst mode.  Then the relocation function itself is an unfinished piece from
the PR14179 runtime split, but it will need dyninst-specific implementation.

We certainly have access to all the relocations from stapdyn itself, and could
implement something like the vma-tracking of kernel mode, but the trick then is
how to present that to in-target probe handlers.  Some data within shared
memory, I guess, but that has to be a fixed allocation.

The in-target probes could instead use dl_iterate_phdr() to figure it out on
their own, of course only for libraries loaded via glibc.  I don't know how
performant that would be, especially repeated every time, but perhaps it's good
enough for a first round.  If it needs optimization, later we could cache what
pieces we need and even hook dlopen/dlclose to catch changes.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.