From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20301 invoked by alias); 18 Aug 2012 01:39:08 -0000 Received: (qmail 20293 invoked by uid 22791); 18 Aug 2012 01:39:08 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 18 Aug 2012 01:38:46 +0000 From: "jistone at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/14489] New: Revamp probe metadata between modules and stapdyn Date: Sat, 18 Aug 2012 01:39:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime 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: Message-ID: 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: 2012-q3/txt/msg00212.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14489 Bug #: 14489 Summary: Revamp probe metadata between modules and stapdyn Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime AssignedTo: systemtap@sourceware.org ReportedBy: jistone@redhat.com Blocks: 14178 Classification: Unclassified Right now, stap is generating "struct stapdu_target" information in a special section for stapdyn to read and parse. I'm not thrilled with the future of having such a fixed ABI between modules and stapdyn, especially in the face of compile-server or remote targets, where stap versions may be mismatched. One idea is to shift this section to some self-describing textual format, which stapdyn will read and parse. I've experimented a little with this, but it seems rather clunky still. Another idea suggested by fche is for stapdyn to dlopen+dlsym the module to query it directly for its probe information. I like this idea, because we can e.g. infer that a missing dlsym just means it's an older module. I'm currently pursuing this further. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.