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

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.


(Dare I throw mixed-endians in there?  No, no, that would be crazy...)

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