This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug dyninst/15566] Support multiple stap --dyninst sessions on the same processes
- From: "serhei.public at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 22 Jan 2015 22:18:27 +0000
- Subject: [Bug dyninst/15566] Support multiple stap --dyninst sessions on the same processes
- Auto-submitted: auto-generated
- References: <bug-15566-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=15566
--- Comment #4 from Serhei Makarov <serhei.public at gmail dot com> ---
I was working a while ago on getting several Stapdyn modules to run in the same
`stapdyn` loader process. I've put up a forward-ported implementation of my
earlier code, rebased onto a fairly recent instance of the master branch, at
https://github.com/serhei/systemtap/commits/serhei/multiplexing
The overall architecture within the loader is explained by a comment near the
top of
https://github.com/serhei/systemtap/blob/serhei/multiplexing/stapdyn/mutator.h
There are no regressions with the single-module case, but multiple modules have
a range of problems and limitations. In increasing order of difficulty:
- There needs to be a proper naming scheme implemented for distinguishing
shared memory belonging to different script modules. This could be the PID of
the stapdyn command that launched the module (so the full SHM name would be
something like "stapdyn.<PID of stapdyn command>.<PID of server>").
- dlopen()ing multiple instances of the same module, currently fails
completely. This is a regression relative to the earlier version.
- A script which calls exit(), exits all other scripts running in the same
`stapdyn` process. There are similar further things to add, in terms of
adequately separating the effects of script errors, directing the output of
different scripts to different places, etc.
I think I will have to admit defeat on getting this functionality into
Systemtap for the time being. I had some work-in-progress on sharing the
Dyninst session via a server-daemon rather than via a toy 'stapdyn -M' option,
but it does not seem useful to put more effort into it until the basic
multiplexing functionality is working more reliably.
--
You are receiving this mail because:
You are the assignee for the bug.