This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug dyninst/15052] externalvar.exp fails with dyninst
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 23 Jan 2013 00:42:23 +0000
- Subject: [Bug dyninst/15052] externalvar.exp fails with dyninst
- Auto-submitted: auto-generated
- References: <bug-15052-6586@http.sourceware.org/bugzilla/>
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.