From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5266 invoked by alias); 14 Feb 2007 02:10:39 -0000 Received: (qmail 5227 invoked by uid 48); 14 Feb 2007 02:10:26 -0000 Date: Wed, 14 Feb 2007 02:10:00 -0000 Message-ID: <20070214021026.5226.qmail@sourceware.org> From: "hunt at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20070214005619.4037.fche@redhat.com> References: <20070214005619.4037.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/4037] make staprun 32/64-bit interoperable X-Bugzilla-Reason: AssignedTo 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: 2007-q1/txt/msg00326.txt.bz2 ------- Additional Comments From hunt at redhat dot com 2007-02-14 02:10 ------- (In reply to comment #0) > Please investigate why a 32-bit staprun fails to work against a 64-bit kernel. I intentionally disabled it because it was making a lot of code very messy. Also I thought it provided an additional check that the systemtap you were attempting to run was configured and compiled correctly. The code that parses the kernel and module symbols and passes those back to the kernel module for storage passes pointers and structures containing pointers. If staprun has to dynamically detect mismatches and still work, that means more complicated and potentially slower and buggier code. Still, it can be done and isn't really a big deal, but what is the motivation? I am confused about how this situation occurred and why it is desireable to have 32-bit stapruns work on 64-bit kernels. -- What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4037 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.