[Bug dyninst/15053] New: stapdyn needs -G (setting global variables) support

[Bug dyninst/15053] New: stapdyn needs -G (setting global variables) support

[dsmith at redhat dot com]

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

             Bug #: 15053
           Summary: stapdyn needs -G (setting global variables) support
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dyninst
        AssignedTo: systemtap@sourceware.org
        ReportedBy: dsmith@redhat.com
    Classification: Unclassified


Commit a28b50a add dyninst support to testsuite/global_opt.exp. The tests fail
for "--runtime=dyninst", since setting global variables from the command line
isn't implemented.

If it is decided that setting global variables from the command line won't work
for dyninst, stap should disallow specifying '-G' along with
'--runtime=dyninst'.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15053] stapdyn needs -G (setting global variables) support

[jistone at redhat dot com]

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

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> 2013-01-23 00:43:15 UTC ---
Agreed, we need this.

It should be possible, especially now that stapdyn can always call directly
into the probe module - just have to decide what that interface should be. 
I've been debating to myself whether to add more stapdyn.h functions for things
that staprun does in transport messages, or to just add a single transport-like
message interface.

It may also be slightly tricky to juggle the static global-initialization,
which must happen after shared memory init, versus the dynamic -G values, which
still need to be set before any begin probes.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15053] stapdyn needs -G (setting global variables) support

[jistone at redhat dot com]

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

--- Comment #2 from Josh Stone <jistone at redhat dot com> 2013-01-23 00:58:44 UTC ---
(In reply to comment #1)
> It may also be slightly tricky to juggle the static global-initialization,
> which must happen after shared memory init, versus the dynamic -G values, which
> still need to be set before any begin probes.

One possibility for this is to have the initialization in an actual C-global
variable again, and have -G overwrite that early on, much the same as globals
work in kernel mode.  Then when we're initializing the "real" global in shared
memory, we'd pull its starting value from that C-global.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15053] stapdyn needs -G (setting global variables) support

[smakarov at redhat dot com]

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

Serguei Makarov <smakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smakarov at redhat dot com

--- Comment #3 from Serguei Makarov <smakarov at redhat dot com> 2013-03-22 19:38:29 UTC ---
After much discussion, this has been narrowed down to three possibilities for
implementing the customizable variables *without* taking globals out of shared
memory.

- (1) pass the custom values into stapdyn using putenv/getenv (!)
- use a throwaway static struct to hold the default initial values, so stapdyn
can override them using some kind of setter function in the module:
  - (2) either dynamically generate a global_setter_<var>(val) function
per-variable
  - (3) or dynamically generate a single* global_setter(name,val) function that
works like a lookup table

*) actually, two functions, one per type

I'm currently testing a working patch for the third alternative.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15053] stapdyn needs -G (setting global variables) support

[smakarov at redhat dot com]

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

--- Comment #4 from Serguei Makarov <smakarov at redhat dot com> 2013-03-22 21:45:59 UTC ---
Created attachment 6940
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6940
initial version of lookup-table-based patch

Currently testing the attached patch.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15053] stapdyn needs -G (setting global variables) support

[smakarov at redhat dot com]

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

--- Comment #5 from Serguei Makarov <smakarov at redhat dot com> 2013-03-22 22:39:48 UTC ---
Pushed cleaned-up version of the earlier patch to the repository.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug dyninst/15053] stapdyn needs -G (setting global variables) support

[smakarov at redhat dot com]

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

Serguei Makarov <smakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Serguei Makarov <smakarov at redhat dot com> 2013-03-28 13:47:16 UTC ---
Finished double-checking the testsuite results with the -G enhancement; no
additional failures means I can probably close this PR.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.