• No results found

The normal sampling period employed bv the PC-sampling method is based on the hard clock

In document dtj v07 04 1995 pdf (Page 104-109)

( C:LOCK_RENTIME) of the Digital U N I X operating

system . This method resul ts in

l

,024 samples being

taken per second, which provides a timing resolution of976 microseconds, or approximately l millisecond.

The routines that make u p a real-time application

typically take from a tew microseconds to several milliseconds to execute . Attempting to measure the

execution time of routines that take less than l m i l ­

lisecond t o execute with a clock resolution o f

l

milli­

second can lead to erroneous results. A test on a 1 50-megahertz ( MHz) Alpha 2 1064 CPU showed

that the prof tool, using the normal PC-sampling rate,

reported the execution time of a routine to be 4 milli­ seconds when the true execution time was 20 micro­ seconds. (The true execution rime was measured using

the Parasight tool set. )

It is possible to increase the sampling rate using the uprofile uti lity, but doing so also proportional ly increases the number of interrupts per second that the system must handle. For instance, to obtain even 10-microsecond resolution would require the system to handle 100,000 interrupts per second. This amount of i nterrupt activity would rapidly swamp the system, l eav­ ing little or no CPU rime to execute the program being instrumented. The PC-sampling method of execution analysis is therefore not suitable for the short execution

times typical in real-rime application routines.

The block-counting method, a lthough capable of high-resolution measurement, sufters from the inabil­ ity of the pixie utility to work with programs that receive signals. Most real-time applications use signals for program scheduling and are therefore disquali fied from using the block-counting method .

In addition to the problems just discussed, the tradi­ tional

U N I X

profiling tools are unsuitable for real ­ time program execution analysis for the following reasons:

• A program must be preprocessed for protlling

prior to execution. Adding or removing profil ­ ing requires stopping, processing, and restarting the program . This assumes that the problem area is known before the application starts to r u n . If a problem suddenly develops after an u ninstru­ mented program has been running for 24 h ou rs, the user will have lost the opportunity to determine which routine is causing the problem.

A

program must be profiled as a whole, unless source code modifications are made to the program to control the protiling. This can cause excessive overhead, which real - time programs usually cannot tolerate.

The profiling results cannot be seen until the pro­ gram termi nates, unless source code modifications are made to the program to permit the results to be dumped on command . The user needs to see the results while the program is running a nd often needs to repeat a rest several rimes to get the

desired results. Stopping and restarting the applica­ tion once for each test could be laborious.

• Only the average and cumu lative times for each

routine are available. That is, the i n d ividual execu­ tion times tor each call to a routine are not avai l­ able. This a lso precludes the examination of the cal ling sequence .

• The results cannot be cross-correlated between

programs to provide i n formation about the rela­ tive calling sequences between programs or across processors.

A real-time execution ana�vsis

tool must operate

with sufficient resulution to measure the execution time

of

a routine that may take 10 microseconds to

execute.

The instrumentati

on

should be dynamical�y

insertable into the current areas of interest and should be able

to

move to new areas of interest as required-all without stopping and restarting the real-time application.

Parasight: A Solution for Real-time Debugging and Program Analysis

Parasight is an integrated set of rea l-time debugging and analysis tools with a graphical user interface . The tool set consists of a debugger ( Debug ) , a data monitor

( Data Mon

),

and a program analysis tool ( Paragraph ) .

The Parasight tool set solves the real - time deficiencies found in d bx, prof, and the other conventional

U N I X

debug a n d analysis tools used u nder t h e Digital

UNIX

operating system . Parasight is able to debug applica­ tions in either a dynamic (running) or a static (stopped ) state; i t can perform debugging and program execu­ tion analysis on several programs simultaneously, with­ out adversely affecting the dynamics of time-critical applications.

Parasight's Foundation

The Parasight tool set features the use of a symbol table, the /prof tile system, global memory, and scanpoints.

The Symbol Table, .pg File, and /proc File System Parasight's source of knowledge about the target application is derived from the symbol table and the .pg fi le. Both are generated at compile time as a result of the -para special compiler option.

Parasight manipulates target applications by using the /proc file system services available under the Digital

U N I X

operating system. The /proc ti le system enables Parasight to control the program flow and to read and write any memorv address i n the target application. Global Data Just as the traditional means of debug­ ging real-time applications depends on global memory regions, Parasight uses the global memory access

concept as th<.: basis For accompl ishing most oF its advanc<.:d capabilities. Parasighr eith<.:r accesses th<.: target program data directly, through the use of /proc, or uses global memory to acc<.:ss cbta gathcr<.:d t("Jr Parasight b�· one of its scanpoints .

Sca n po ints Th<.: Parasight tool s <.: t uses global m e m ­ o r y access whencv<.:r possible t o prm·ick nonintrusivc access to the target appl ication . Certain functions, howev<.:r, r<.:quire access to data that is local to a pro­ gram. Parasight accesses this data through smal l seg­ m ents of cod<.: called scanpoin ts.

A scan poi nt is a tl1nction that is dvnamically inserted i nto the target program bv Parasight. The scanpoint function then runs i n the same context as the target program and thus has access to all the local data of the program. The scanpoint function works as an agent for Parasight, gatheri ng data that Parasight does not have direct access to. The Parasight tool set uses two principal types of scanpoints: datamon-scanpoints, which arc used bv Data Mon to perform local data monitori ng, and sensor-scanpoints, which are used by

Paragraph to perform program execution analysis.

Inserting the scanpoin ts does not require modi�•ing the application's source code or preprocessing the application's object code. The only requirement is to link each program with the special -para option . This adds a memory buffer to the target program for use by Parasight. The buffer is benign u ntil used bv Parasight. Parasight d\'11amicallv inserts scanpoints bv using the /proc service to build a scanpoint template in the specia l buffer of the target program . This can occur even while the program is running. The template code contains the fu nctionality to

• Sa,·e the register state that existed when the pro­

gram count<.:r \\'aS at the scanpoim insertion location

• Set up the arguments to the scu1poinr function , including the register state

Call the scanpoinr fi.mction

Restore the register state

Execute the instruction that ,,·as originally at the

insertion location

B ranch back ro the i nstruction fol lowing the inser­

tion location

Parasight then dynamically alters the template code according to the insertion location and the instruction con rained therein. If the i nstrucrion was a branch con­ trol instruction , Parasight alters the instruction's dis­ placement so that the location corresponds to the instruction's nn,· displaced location ,,·ithin the tem ­ plate. All other instructions, including j u mp control instructions, do not require altering and arc simply copied to the new d isplaced location .

Once this code is constructed in the bufter, Parasight COlll[)lctcs the scan point insertion process by

l 04 Digiral Tc(hnic.tl )ourm l \'ol. 7 l:'\o. 4 1 995

ov<.:rwriting the instruction at the insertion location

with a branch to the newly g<.:nerated scanpoint template. The f!xed instruction length o f Digital's Alpha microprocessors si mplifies this step e normously. It is important to note that the scanpoint is built bv Parasight, not the target program. The target program

is aftected onlv Lw the tlnal step of the scanpoint inser­

tion, when Parasight 0\'CniTites the instruction at the insertion location. This design prc,·enrs <.:xcessi,·e inter­ terence of the target program. Scan points an.: written in highly optimized code to minimize the impact on the target application when thev are executed.

Parasight dvnamically deletes scmpoi ms bv writing back the original i nstruction at the insertion location. This design al lows Parasight to disable a scmpoint even if the scanpoinr function has not completed .

Meeting Requirements

Parasight has the capabilities required ofdkctive reai­ time debugging and analvsis tools.

Debugging Running Programs Com e ntional C:\IX

de buggers deliberate!\' stop a program '' hen attaching to it, because these tools do not operate on running programs. vVhen Parasight's debugger, Debug, attaches to a program, there is no impact on the program.

Conve n tional

U N I X

debuggers refuse to access any data while a program is running, even though global data resides at fixed memorv l ocations that are accessi­ ble at all times through the /proc sen ice. The reason tor this limitation of the conventional

U N I X

tools is unclear. Parasight's debugger is able to examine and to change the value of any global dara while the program is running or stopped .

Coll\·entional

U N I X

tools also refuse to set any breakpoints in a program \\'hile the program is run­ ning. Agai n , the reason t(x this constraint is un kno\\'11 . Par:.1sight's debugger is :�ble to i nsert bre:�k.points into running programs, a feature that is val u :�ble in debug­ ging error conditions in real -time applicJtions. Debugg ing Mu lti ple Programs PaLlsight's Debug, DataMon, and Paragraph components constitu te an integrated set of tools capable of \\'orki ng on one or more applications simultaneoush·, as sho\\'n in Figu re

1 . The Parasight main window displavs the programs ( and any child ren th<.:y create ) attached to Parasigbr. The window a lso provides an easy mechanism to access the Parasight tool for each specific progr:1m.

Monitori ng Va riables Constantly Parasight's DataMon tool allows the user to simultaneouslv monito r the val ues of anv local or global variables in one or more stopped or running programs. Parasight constantly monitors the v:-tlues Jnd shows any ch:111ge on the DataMon display scree n . DataMon is �1lso capable of displaving th<.: m i n i m u m , maxim u m , :-t nd J\Tragc

80 81 83 41 42 43 87 •• 47 32 92 94 97 55 39 27 102 59 31 103 32 1Q4 33 105 62 lOG 63 47 107 lOll 109 110 51 ltl 52 69 53 113 70 42 114 71 43 115 72 .. 73 57 117 74 47 119 128 77 61 63 67 57 69 63 Fig ure 1 J celD'a

accoW'tt .. ,init(illt to;krMm) I

lnt. iJ

dp-)cpunun[ted:f'k.tl"] • o;

inl ar.LusecCint ta:oknun)

I

r-eturn ( Unt ) t11'18f'64_uo•c ( dp->cpu

J lend if

I VWIUJ'Ih•: 11'0 1 5-7 I ExpressiCM1

...

unSlgntd lnt tKocUme • 16J (DI<aJ)

dp->stoptiM[tukrM.M I • pt .. usec( tas-ltllll'f'l) :

dp->mcectb•eltHki"'UMI = dp-htopUne(taaknuNJ .. dp->t:tartt.-lt.,..ounh

if

tt!-��:=��::.:�"�11Xt".;Ai\":.t.oa) )

if ( dp-)exectine[tuknl.l\] < dp-)t�lntinc(taskrutl )

dp-)ftintl,.. ltukrtu��l • dp-)exectl�te[ted:.ll!.Ml;

dp->rraftti..eltasknu" 1 • dp-htoptine[ tllskMmJ - clp-)etartiMIOl J

dp->t.oHinelt.sknur.l •• dp-)oHoctino[t.ukRW�lJ

dp-)pa;o:.cnt.li(tulmutl ]HJ

dp-)toskstathasknun) • CDHPLETEl

H < taaknu.. == dp•>1uttask )

dp-)donetillleldp-)(t'a.llll] • pt_usec(tackntM) J

P;lr;lsighr's Debugger Working "·irh FiH: Tasks Simultaneouslv

values attained ror any variable. A scrolling history display along with a time stamp is also ava ilable for solving transient problems.

The variables to be monitored can be selected using the mouse on the Debug browser or entered i nto a dia­ log box using the kq,board. The Data Mon graphical user interrace has a poi nt-and-edit capability, which a l lows the user to edit the mnemonic data ( i. e . , name, display format, va lue, location, or com ment) directly on the screen . The user can store mnemonic lists on d isk for fast n.:tric\·::d \\'hen requi red . Figure

2

shows a DataMon d isplay screen.

DataMon is able to monitor global data completely and nonintrusivdy using the /proc service and uses

a datamon -scanpoint to i mplement local data mon i ­ toring. The daramon-scanpoi nt i s attached to the

Data Mon database, which is a shan:ci memory region connecting all the scan points and the Data Mon display progra m . The datamon-scanpoin rs deposit the val ues of local data into the database for the displav program to show on the screen . Datamon-scanpoints are :�lso used to change the values of local data, depositing the value fl·om the database into the specitled variable.

Data Mon uses

the

Debug tool's expression evaluator

to parse the required m nemonic to derive the location of the value ro be displayed . This mav include register access for l ocal variables saved on the stack. Multiple m nemonics can be monitored locally at the same location since a datamon-scanpoint function can tra ­ verse a list of mnemon ics to be monitored.

Note that DataMon monitors data asynchronously; therefore, DataMon cannot guarantee to d isplav evcrv

stllrtime

dp->stoptime[ tasknuml

dp-)exectirne(tasknum]

d p - >m

i

ntime[tasknuml Dec dp->maxtime[ tasknuml Dec

dp- > f'r�rf'l t l m e ( t�sknurnJ Dec 735 < 735 < 2064 dp-> passcnt s [ OJ Dec 4 216 dp- > passcnts [ 1 l Dec 4 216 d p - > passcn t s [ 2 J Dec 4 2 1 5 d p - > passcnt s [ 3J Dec 4 2 1 5 d p - > p a s s cn t s [ 4 ] Dec 4 2 1 4 l oops Dec 49449067 dp-> numtasks Dec 1 0 tasknurn Dec 4 Fig ure 2

The DataMon Display Screen with History Window

DataMon [ 1 56 4 ] [ 1 56 4 ] [ 1 564] [ 1 564] [1564] [ 1 56 4 ] [ 1 56 4 ] [1564] [ 1 56 4 ] [ 1 56 4 ] [ 1 56 4 ] [ 1 572] [ 1 565] [ 1 573] ** Global account . c : 60 accou n t , c : 6 0 account . c : 6 0 a c c o u n t , c : 6 0 accou n t , c : 6 0 task3 , c ; 1 02 mai n ( ) exec . c : 1 4 4 mai n ( ) account . c : 51 16�07:0] llp->rrr4mlilut!:[l.,.!lkfllllll) '"' J�!'i 1&:07:03 dp->lnunlimo(l831<numJ -7�7 r•:oJ:Ol dp-�ftiUTltlmt(ta'SblumJ = 79' 1&:07:0-1 dp->lnunlime(l831<numJ -804 r':OJ:O.J np- ·.•rrarntlmt[ta1t.numJ = 791 1&:07:0-1 dp- >lnunlime(l831<numJ -80G n::UI :U·l dp- :-friUTltJme[tasknumJ -/ti:J 16:07:05 dfo - •framtime(l&knumJ • 700 n:ut:Ju ttp-:-rr.mt�me!tasknumJ -1�-1

flii:OC� Ht-!lp

value that the variables reach . For global data, Parasight records only the minimum and maximum

v

al

u

e

s that

DataM o n sees. For local data, however, the scanpoint keeps track of

the minimum,

maximum, and average val ues, so these

can

be guaranteed. Parasight can also moni tor global data by usin g a datamon-scanpoint to moni tor the value at a particu­ lar line of code.

On-the-Fly Execution Analysis Paragraph displays

static source-code call graphs of the application's programs, i l lustrating the hierarchy of function calls, system calls, and statement-level control flow. Point­ and -click operations allow the user to quickly view the source code for any program or function, thus simpli ­

fy

ing the

task

o f

analyzing

source code. Figure

3

shows a Parag raph call graph and browser.

lnslnlment VIew Conte><! �etup

Figure 3

Paragraph Call Graph and B rowser

1 06 Digital Technic<! Jomnal

•inc lude '"dp .h" linclude .. exec . h "

int perJodc.olc{int t�sknun) I

stdtic un�igned int l.c�s:t._sldrtine[ MRXTASJ(+l] �

dp->star·ti"e[ tasknunl = eut_usE:c{tasknun } ; i f ( dp-)pi)SScnts[tasknun J > 1 >

I

dp->per lod£ tasknunl = dp->startirte[ tasknun J -last_slart 'inc [ task nun l ; dp-}lotperiod( tasknurtl • = dp->per�iodl tasknu" l ;

i f ( dp-)period ( t.asknun J < dp-)niuperiodl tasknu.,) I� Min p�r.iod •I

dp-)n.inperiod [ tasknunJ = dp-)p"riod(t-c�sknuft];

if ( dp-)per iocHtasknunJ ) dp-)naHp�riod( tasknunl /* HaM period 'f>/

dp-)nawperiod [ tasknunl = dp-)peri.od.(t.l�knurtl � last._st.artlne[t.asknunl = dp->starti"e[ task nun J ;

Call graphs are also used to define where to insert

In document dtj v07 04 1995 pdf (Page 104-109)