<<>> <> <> <<>> Druid PCEDAR 2.0 % FOR INTERNAL XEROX USE ONLY Druid A PCedar performance & debugging tool Peter B. Kessler (based on code by Russ Atkinson) Ó Copyright 1990 Xerox Corporation. All rights reserved. Abstract: Druid is a package that can be used to count how many times control passes through given points in the system. Created by: Russ Atkinson Maintained by: Peter B. Kessler Keywords: breakpoints, debugging, fast breaks, performance, performance measurement, programming tools XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 For Internal Xerox Use Only Druid Druid is a package that can be used to count how many times control passes through given points in the system. Although much more limited than the Spy, it is also more interactive and perturbs the system less. Counting breakpoints can be set on high-priority processes or even in code as sensitive as SafeStorage allocation. The Druid interface provides procedures for setting, clearing, and querying counting breakpoints. Counting breakpoints can either be monitored or unmonitored. All changes to monitored breakpoints (e.g. incrementing or zeroing counts) are done under a monitor lock (one per breakpoint). Monitored breakpoints are recommanded for almost all uses. Unmonitored breakpoints just get in there are change their data. Unmonitored breakpoints are recommended for breakpoints inside the monitor entry and exit code in the system, etc., where you can't afford to entry a monitor to update the counter. DruidTool DruidTool is a tool that can be used to set, clear and display Druid counting breakpoints. The DruidTool has the following menu buttons: ClearAll clears all breakpoints set by this DruidTool ZeroAll clears the counts of all breakpoints set by this DruidTool Set sets a monitored counting breakpoint using the selection UnmonitoredSet sets an unmonitored counting breakpoint using the selection AddSubTotal adds a subTotal line to the display Freeze freezes the display so DruidTool updates don't interfere with watching other viewer events. Sample causes DruidTool to update its display while still frozen. Thaw thaws the DruidTool display so it updates periodically. Each line in the display represents a separate breakpoint. Each line has two buttons, clear and zero, which are used to clear the associated breakpoint or to simply reset its count to 0. These buttons are followed by the count, which is updated every second. Following the count is the location of the breakpoint, consisting of: location the IconHacks label for the file and the position containing the breakpoint (or the full name of the file, if no label is found). This viewer is actually a button that will display the location of the breakpoint. selection the contents of the selection that was used to set the breakpoint. This is useful for distinguishing the breakpoints. If you are an old Celtics user, it takes a while to get used to making useful selections when setting breakpoints. Things that still need work: There used to be a DisplaySummary button to dump the current samples to a typescript. I don't think that's hard, it's just that enough of it worked that it seemed like a good idea to release it. Celtics uses BackStop to catch and display errors. The PCedar version of BackStop is no good at displaying errors, so I took it out. Let me know what errors get through, and I'll put in catch phrases for them. As soon as I figure out how to get the module and procedure names for an address out of Cirio, that will probably replace the current location column. The idea is that the file name is uninteresting, especially if you can click on the module and procedure button and have it open the file for you. Now that there can be several DruidTools, there should be a way to label them. Command line arguments are the obvious source of labels. Unfortunately, you can only plant Druid breakpoints where you can find code addresses. For DruidTool, that means in unoptimized code, since DruidTool uses Cirio to find code addresses. If you are planting your own Druid breakpoints, you can put them on procedure entry points pretty easily, and other places with more work. Druid uses Cirio to map source locations to addresses. Cirio has facilities for caching information about loaded modules, and Druid makes use of those caches to make setting subsequent breakpoints in a file considerable faster than setting the first breakpoint. Unfortunately, though Cirio builds the cache, it has no way of telling when the information in the cache is out of date, so if you reload modules with breakpoints in them, you have to crank up a new DruidTool to get a clean cache. I tried adding a FlushCache button, but it was too dangerous (because Cirio still used the old one), and didn't buy you anything (because your old breakpoints had to be cleared anyway), so you might as well just get a new DruidTool. SameBreakWorld SameBreakWorld is a much simpler interface to Cirio, primarily designed to be useful to DruidTool, but others might find it useful for other interactions when setting breakpoints in the same world.