This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug dyninst/14490] Enable stapdyn in multiarch environments
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 07 Jun 2013 20:21:32 +0000
- Subject: [Bug dyninst/14490] Enable stapdyn in multiarch environments
- Auto-submitted: auto-generated
- References: <bug-14490-6586 at http dot sourceware dot org/bugzilla/>
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.