This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dyninst/14490] Enable stapdyn in multiarch environments


http://sourceware.org/bugzilla/show_bug.cgi?id=14490

--- Comment #5 from Josh Stone <jistone at redhat dot com> ---
(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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]