From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19186 invoked by alias); 23 Jan 2013 00:42:52 -0000 Received: (qmail 17535 invoked by uid 48); 23 Jan 2013 00:42:24 -0000 From: "jistone at redhat dot com" To: systemtap@sourceware.org Subject: [Bug dyninst/15052] externalvar.exp fails with dyninst Date: Wed, 23 Jan 2013 00:42:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: dyninst X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jistone at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2013-q1/txt/msg00047.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15052 Josh Stone changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jistone at redhat dot com --- Comment #1 from Josh Stone 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.