From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13271 invoked by alias); 14 Feb 2007 02:28:12 -0000 Received: (qmail 13237 invoked by uid 48); 14 Feb 2007 02:28:01 -0000 Date: Wed, 14 Feb 2007 02:28:00 -0000 Message-ID: <20070214022801.13236.qmail@sourceware.org> From: "fche 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/msg00328.txt.bz2 ------- Additional Comments From fche at redhat dot com 2007-02-14 02:28 ------- > I intentionally disabled it because it was making a lot of code very messy. Indeed, which made sense in the absence of a target-neutral "wire protocol" between the kernel and staprun. That is in effect what I am proposing be developed. Consider it an enhancement if you like. > [...] I am confused about how this situation occurred and why it is > desirable to have 32-bit stapruns work on 64-bit kernels. At the moment, the issue arises on "multilib" (really, multi-ISA) architectures where a kernel can run more than one type of binary transparently. Hence the wrong staprun might get installed, even though they both would "work" as far as being executable is concerned. This gets even more entertaining should the same machine be equipped to run either 32- or 64-bit kernel, with a primarily 32-bit userspace. It would be nice to avoid requiring reinstalling staprun just because one rebooted. -- What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW Last reconfirmed|0000-00-00 00:00:00 |2007-02-14 02:28:01 date| | 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.