| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 539.1 | PCA? | BARAKA::LASTOVICA | Certified hot tub life guard | Thu Aug 27 1987 01:08 | 5 |
| For a process level version of this, check out PCA (performance
and coverage analyser). On a system level, you've got a bunch of
hacking to do, but I believe that you are on the right track. Some
system services do record statistics about what they do (QIO's come
to mind) but not all QIO calls would tick a counter.
|
| 539.2 | SPM ? | IOSG::BAILEY | DO: $CMKRNL_S Routin=Hack... | Thu Aug 27 1987 09:46 | 7 |
| Well if I follow the question correctly then why not use SPM
(the Event Traceing bit), the example provided with the
install does (I think) just what you are looking for
Peter Bailey
|
| 539.3 | | WKRP::LENNIG | Dave, SWS, @CYO Cincinnati | Thu Aug 27 1987 14:02 | 17 |
| re: .1
My understanding of PCA is that it must be linked with the program
of interest. This is not an option in this case, as part of the
customer's desires are to instrument already linked programs,
specifically product type images for which no sources or objects
are provided.
The facilities that PCA provides are very similar to those desired.
Hmmm. Maybe there is some way I can hook the PCA sharable images
in the control region on a process permanent basis??? Comments?
re: .2
SPM has such abilities, but are system wide, instead of process
specific. I'll keep this in reserve.
Thanks, and keep it coming,
Dave
|
| 539.4 | Digital has it now (or something like it anyhow)! | DUNE::LASTOVICA | Certified hot tub life guard | Thu Aug 27 1987 14:38 | 12 |
| It is VERY possible to use PCA without relinking. However, you'll
have to do a bit of hacking to turn the debug bit on in the image
header. If the image was linked /notrace then you'll also have
to fudge the vector there. Please get the PCA manual and check
these things out. You'll also have to experiment a bit since I
don't know if PCA relies on a symbol table to find the system servce
vectors. It may well not. I think this is your best bet!
The debug bit is the LSB of byte 20 in the image header (as seen
by PATCH/ABS). There is a note somewhere (VMSNOTES?) that'll tell
you how to fixup the vector where the traceback is indicated. If
you get stuck for it, I've probably got a copy around (somewhere).
|
| 539.5 | TLE::DEBUG #308 | GOFER::HARLEY | Shoes for Industry | Thu Aug 27 1987 15:21 | 0 |
| 539.6 | I use SPM. | VAXWRK::NEEDLE | Jeff Needle | Thu Aug 27 1987 15:53 | 4 |
| I've always used SPM. You can collect system wide statistics and
then extract those specific to a particular pid.
j.
|
| 539.7 | | ATPS::MALLORY | You won't know if you don't ask. | Fri Aug 28 1987 01:55 | 12 |
| RE .2
You are correct. The ETF example that ships with VAXSPM is a
system service monitor that will do what your customer is looking
for. Beware - this 'example' will be changing for VMS V5.0
For more information on etf see HITECH::SPM_ETF and HITECH::VAXSPM
KP7 adds HITECH::SPM_ETF to your notebook.
Kevin
VAXSPM Development and current SPM ETF Maintainer.
|
| 539.8 | | IOSG::BAILEY | DO: $CMKRNL_S Routin=Hack... | Fri Aug 28 1987 11:11 | 11 |
| RE .6
> You can collect system wide statistics and then extract those
> specific to a particular pid.
Or to reduce the amount of data collected, do the match on
Pid in your trace point routine (store the Pid in EXE$GL_Sitespec
to avoid 'hard codeing' the pid ?)
Peter Bailey
|
| 539.9 | | ATPS::MALLORY | You won't know if you don't ask. | Fri Aug 28 1987 15:09 | 7 |
| You can also tell the PCsampler what pid you want to collect on.
$ PERFORMANCE COLLECT=SYSTEM_PC/ID=pid
Kevin
VAXSPM Development
|
| 539.10 | Thanks (I think) | WKRP::LENNIG | Dave, SWS, @CYO Cincinnati | Tue Sep 01 1987 14:44 | 5 |
| Thanks for the input folks. I've passed on these options to the
customer, and they are satisfied/off to write ETF code.
I, on the other hand, am bummed out about the lost opportunity to
do some neat hacking (at their expense). Oh well...
|
| 539.11 | | PSW::WINALSKI | Paul S. Winalski | Tue Sep 08 1987 01:45 | 17 |
| The "cleanest" way to do this would be to do system service intercept on a
per-process basis. This involves replacing the P1-space system service vectors
with a set of your own vectors. A system service call within the process
then winds up calling your code. Your code can then increment the appropriate
counter and call the real system service. This is totally transparent to the
user program and can be done on a per-process basis. It is how VAX DEBUG
handles watchpoint interactions with system service calls.
I used to know how to do this. Stan Rabinowitz once wanted to intercept RMS
calls to do a "auto-MMS" file operation tracer. I set up a system service
intercept module that would let him trap RMS calls. You can grab any and all
system service calls this way. Unfortunately, I don't remember the particulars
of how it's done any more. I think Stan's and my code is in the Toolshed
these days. Failing that, you can look at what DEBUG does (I think the
relevant module is called DBGSSI).
--PSW
|