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 #4 from David Smith <dsmith at redhat dot com> ---
(In reply to Josh Stone from comment #3)
> If we create a stapdyn32, that means we also have to have dyninst in 32bit. 
> This stapdyn32 also would *only* be capable of probing 32-bit targets.  So
> at this level, I don't see much value in multiarch -- people who know
> they're targeting 32-bit apps could use an entirely 32-bit stap to begin
> with.

In case I didn't specify out my brute force idea very well, here you go. A user
would still run 'stap --dyninst -c target_exe script.stp'. Then, based on
whether target_exe was a 64 or 32 bit app, stap would run either stapdyn or
stapdyn32. If we want to push that down a level, stap could just run 'stapdyn'
which would be a simple program that looks at target_exe, and then exec either
'stapdyn_real' or 'stapdyn_real32'.

I guess this brute force approach is more 'biarch' (i.e. able to handle more
than 1 arch, but only one at at time) then 'multiarch' (i.e. able to handle
multiple arch simultaneously).

>From a user's point of view, I think there is some value here. Perhaps not an
incredible amount, but some.

On to your next point...

> The real value of multiarch IMO comes with mixed targets.  Perhaps a 64-bit
> initial application will fork/exec a 32-bit worker process, etc.  All of
> this monitored with a single stap session.
> 
> Of course, my opinion now doesn't mesh with my comment #0 about matching
> archs in stapdyn.  We do now dlopen the stap module in stapdyn, and we
> obviously can't do that for both -m64 and -m32.  To make those
> interoperable, we'll need the same module compiled in both modes, able to
> talk to the *same* shared memory.
> 
> So everything in shm would have to be constructed in an arch-neutral
> fashion.  Structs have to be careful about padding, offptr_t has to use a
> fixed size for its offset, etc.  Some parts are mostly just a shared reserve
> of memory, like the context allocations, so that may not have to completely
> line up, though a few bits within really are shared.

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

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).

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.

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.

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.

-- 
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]