From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21070 invoked by alias); 10 Jun 2013 18:05:30 -0000 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 Received: (qmail 21028 invoked by uid 48); 10 Jun 2013 18:05:25 -0000 From: "jistone at redhat dot com" To: systemtap@sourceware.org Subject: [Bug dyninst/14490] Enable stapdyn in multiarch environments Date: Mon, 10 Jun 2013 18:05: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-Version: unspecified 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-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q2/txt/msg00262.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14490 --- Comment #5 from Josh Stone --- (In reply to David Smith from comment #4) > OK, so here's my understanding of what you're thinking here. > > - the shared memory segment created by the shared library needs to be bit > size agnostic, using arch neutral types and padding > - stap always compiles 64-bit and 32-bit shared libraries > - stap runs stapdyn, which is always 64-bit, and it always loads the 64-bit > shared library > - We load the appropriate shared library in the target based on the target's > 'bitness' > - the target shared library (either 32-bit or 64-bit) and stapdyn's 64-bit > shared library communicate through the shared memory segment Yes. > I think from the stap side of things that looks reasonable and doable. Of > course we've still got the dyninst problem you mentioned in comment #0 (the > single DYNINSTAPI_RT_LIB variable). Yes, that's something to address in dyninst itself. > Note #1. We've got a problem with cached shared libraries (and stapdyn > execution in general I guess). In theory you should be able to say 'stapdyn > foo.so -c target_exe', but we need both the 32-bit and 64-bit of foo.so if > target_exe is a a 32-bit executable (we need the 64-bit for stapdyn and the > 32-bit for the target). Perhaps instead of the shared library name, stapdyn > will need to take a directory name (that is assumed to contain the 64-bit > and 32-bit shared libraries). I guess our other option here would be that > stapdyn takes 2 shared library arguments. I'd say just put m64/m32 in the cached names, give the native (m64) version as normal to stapdyn, and add an optional --compat filename.so for the m32 version. > Note #2: How do we ensure that the 64-bit and 32-bit shared libraries were > built from the same source (and therefore expect the shared memory to be > laid out the same way)? Perhaps we'll need to checksum the source and put > that value in the shared memory segment and both libraries need to agree on > the value. Sure, just a checksum or uuid of some sort is fine - we don't need to be *too* clever here. We want to prevent accidents, but don't need to bother with someone who deliberately tries to abuse this. It's more like the buildid checks we do for targets, just a basic sanity check. > Note #3. Down the road we may have an RPM problem, since I'm not sure that a > 64-bit stap RPM can require both the 32-bit and 64-bit versions of dyninst. I'm not sure whether we may, but I don't think we should require it. People who are doing multiarch probing can be advised to install dyninst.i686 (or ppc32, etc). For the approach which does it all via shm compatibility, only libdyninstAPI_RT.so is actually needed in 32-bit. That's not packaged on its own, but it could be. -- You are receiving this mail because: You are the assignee for the bug.