windsh and browserread.pudn.com/downloads20/sourcecode/embed/68037/tornado tr… · the target from...

Wind River SystemsTornado Training Workshop © Copyright Wind River Systems 3-1

Chapter

3

WindSh and Browser

WindSh

Browser


WindSh and Browser

3.1 WindSh

Browser

WindSh

C and Tcl Interpreter

WindSh Built-in commands


WindSh

• Interactive C-expression interpreter allows:

● Accessing VxWorks facilities

● Downloading and invoking code

● Creating and examining variables

• Interactive Tcl interpreter allows:

● Defining user commands

● Automating interactions with target.

• For UNIX hosts, invoke from the Launcher. (UNIXHost)

• For PC host, invoke from the Tornado development

environment Tools menu or launch toolbar. (PC Host)

• Tcl is the Tool Command Language, a powerful scripting language. See

Ousterhout’s Tcl and the Tk ToolKit for information on Tcl.

• See the Tornado API Guide for information on Wind River’s WTX

extensions to Tcl.

• Must be knowledgeable user.

• Can run multiple shells per VxWorks target.

• WindSh provides partial support for C++.

• WindSh can be started from the command line by executing windsh.


How the Shell Interprets Commands

• WindSh uses the target server’s system symbol table

and the following rules to interpret names in

expressions:

-> retVal = printf (“Foo is %d\n”, foo)-> i (tWdbTask)

1. Use a WindSh built-in command in preference to atarget symbol of the same name.

2. Look for symbol in the symbol table.

3. Look for _symbol in the symbol table.

4. Convert a task name to a task ID.

5. Create symbol if it is to the left of ‘=’ and does notexist in the symbol table or as a task name.

• Built-in functions are implemented in the shell and execute at least

partly on the host. The shell command i() is a built-in function which

prints out information about VxWorks tasks. We will see and use many

other examples as we go through the course.

• A task ID is 32-bit number which uniquely identifies a task. Task IDs are

discussed in the Real-Time Multitasking chapter.

• When a symbol must be created, the target server allocates memory on

the target from the target server’s memory pool and stores the new

symbol in the host-based symbol table.

• For some target architectures, the C compiler prepends an underscore to

the names of symbols in program code. This is the reason for rule #3.

However, WindSh will match xx with _xx even when the target is not

one of those for which the compiler prepends an underscore.


System Symbol Table

symbolname

Pointerto memory

Type

_printf

_accept

x 0xda188

0000000A

Memory

0xda188

-> x = 10new symbol "x" added to symbol table.x = 0xda188: value = 10 = 0xa

bss

text

text

0x29622

0x2afd4

• Allows interactive access to subroutines and global variables.

• “Type” indicates the program "segment" to which the symbol belongs:

text, data, bss, or comm.

• The symbol table is stored on the host and managed by the target server.

Consequently, development tools use fewer resources on the target.

• Text segment information on the target is assumed not to change, except

under the target server’s control, so it is cached by the target server on

the host to improve debugging performance. The default cache size is 1

MB.


WindSh as a C Interpreter

• Shell command syntax is generally the same as the C

programming language:

-> x = (8 * 6) / 4x = 0x20ff378: value = 12 = 0xc

-> Nom = “Nelson”new symbol “Nom” added to symbol table.Nom = 0x23fe798: value = 37742496 = 0x23fe7a0 =Nom + 0x8

-> printf (“Hello %s, number is %d.\n”,Nom, 0x20)

Hello Nelson, number is 32.value = 28 = 0x1c

-> &xvalue = 34599800 = 0x20ff378 = x

• You can manipulate any global variable:

● Examine the values of your program’s variables.

● Change the values of variables.

● Create new variables.

• You can invoke almost any function in memory:

● When invoking a subroutine, shell passes ten arguments to thesubroutine, padding with zeros if necessary.

● The shell prints the values of the function call (and other) expressionsit evaluates.

• Note: by default, standard output from a target function called directly

from the WindSh appears in the WindSh window.


Syntax Quirks

• WindSh built-in functions screen target symbols of the

same name. To access the target symbol rather than the

built-in, prefix its name with ’@’ :

-> @i = @i + 3

• Target functions are always called (spawned) with 10

integer arguments. For example,

-> 2 * foo (&mac, 27) is really-> 2 * foo (&mac, 27, 0,0,0,0,0,0,0,0)

• If the entire expression is a function call, with the

function name first on the line, parentheses may be

omitted:

-> foo &mac, 27 but not-> 2 * foo &mac, 27

• When the WindSh evaluates a function call to a target function, it is

really spawning a new task on the target to execute that function. Any

excess arguments are ignored by the function’s executable code.

• From the Tornado tools, calling functions expecting floating point

arguments is problematic. It may work on architectures which expect

such arguments to be passed on the stack, but fails if the target

architecture expects the arguments passed in particular floating point

registers. There is, of course, no problem calling such functions from

compiled code.


Caveat - Examining Variables

• The shell interprets all variables as 32-bit integers

unless specified otherwise.

• Casts must be used to tell the shell how to interpret

non-integer types.

-> z = (short) 0x90z = 0x20ff370: value =144 = 0x90-> (short) zz = 0x20ff370: value = 144 = 0x90-> zz = 0x20ff370: value = 9498350 = 0x90eeee

• All variables created in the WindSh are allocated 8 bytes

of target memory, to preserve space in case the

variable’s value is changed to a double.

• Floating-point values are stored as doubles.

-> x = 9.1x = 0x20ff398: value = 9.1-> (double) xx = 0x20ff398: value = 9.1

• Note: WindSh casts are used to assign type information to an

expression. In C, casts are used to convert one type to another.

• The type information specified in a WindSh cast is not retained.


Caveat - Data Structures

• The shell does not recognize data structures. To view

and manipulate data structures, use a source-level

debugger.

• To display memory:

-> d pMyBuf003fe770 0023 09ea e030 2647 a682 eeee * #...0&G....*003fe780 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe790 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe7a0 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe7b0 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe7c0 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe7d0 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe7e0 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe7f0 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe800 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe810 eeee eeee eeee eeee eeee eeee eeee eeee *................*003fe820 eeee eeee eeee eeee eeee eeee eeee eeee *................*

• The d() shell built-in can display data in 1, 2, 4 or 8 byte units. The data

is displayed conventionally, with the most significant byte of a unit

displayed on the unit’s left. On little-endian machines, this means that

for units larger than 1 byte, the order in which the bytes are displayed

left-to-right in the memory dump is not the same as the order in which

they occur in memory; there is a reflection of the bytes in each unit.


Caveat - Macros

• The shell does not recognize symbolic macros (defined

for the C preprocessor with #define directives).

• Must examine header files to find the value

corresponding to a symbolic constant.

• A tool like grep or findstr is useful for finding the value assigned to a

macro.


Symbol Table Look Up

• Display symbols matching a regular expresson with

lkup( ).-> lkup (“stuff”)_stuff 0xda1a0 data (foo.o)value = 0 = 0x0

-> lkup (“^_print”)_printf 0x00029622 text (vxWorks)_printErr 0x00029640 text (vxWorks)_printExc 0x0002965e text (vxWorks)value = 0 = 0x0

-> lkup "^x$"x 0x000da188 bss ()value = 0 = 0x0

• Some C compilers prepend an “_” to symbols declared in the source.

• Use lkAddr( ) to display symbols located near a particular address.

• The Tcl WTX function wtxSymListGet can return a list of symbols

matching a regular expression, and defined within a particular module.

See the Tornado API Guide or online documentation for details.


Shell Line Editing

• History mechanism like the UNIX Korn Shell’s.

• Type h to see list of previous commands.

• Press esc to enter line editing mode.

• Accept changes by hitting return. To quit, type ^U.

• Editing mode uses vi-like commands, including:

h j k l

• By default, there is space in the history list for 20 commands. To increase

this, call h() with a parameter. For instance,

-> h 500

increases the history capacity to 500 commands.

• A complete list of WindSh line editing commands is available in the

Tornado User’s Guide.


Shell Special Characters

Character Description

^C (UNIX) Terminate a function call and^-Break (PC) return shell prompt.

^X (UNIX) Reboot VxWorks target.

^D, TAB Symbol and filename completion;command synopses.

^W Show HTML help for command.

Esc Enter Vi-like editing mode from inputmode.

^U Delete an entire line, return to normalinput mode.

• Use the command or filname completion / synopsis / help keys as

follows:

-> semT type ^D..._semTake _semTakeTbl _semTerminate-> semTa type TAB...-> _semTake type <space> ^D...semTake() - take a semaphore

STATUS semTake ( SEM_ID semId, /* semaphore ID to take */ int timeout /* timeout in ticks */ )-> _semTake (mySem, type ^W to see documentation...

• Pathname completion is similar. It is only attempted if no target symbol

or built-in matches the string, so it is a good idea to start relative paths

with "./".


Shell Built-in Commands

WindSh provides common commands needed fordevelopment:

• sp Create a task with default options.

• td Delete a task.

• ts/tr Suspend/resume a task.

• b Set or display break points.

• s/c Step/continue a task.

• tt Trace a task’s stack.

• i/ti Give (detailed) task information.

• w/tw Show which objects are tasks waiting for.

• ld/unld Load/unload a module.

• show Display object information in WindSh.

• We will see many examples of show in later chapters.

• The commands b(), s(), c() and l() allow assembly level debugging in the

WindSh. ( l() provides a disassembly listing.) In general, it is better to

use CrossWind for debugging because it has all the power of a source-

level debugger.

• See the windsh appendix to the Tornado User’s Guide for a complete

description of all shell built-ins.


WindSh Primitives and TargetResources

• Shell built-in commands execute as C-interpreter

primitives on the host when possible.

● Example: the built-in lkup( ) executes entirely on the

host. No communication with the target is required.

• Some built-in commands require modules to be loaded

into target memory.

● The shell primitive period( ) executes as a function_periodHost on the target.

● The shell primitive repeat( ) executes as function_repeatHost on the target.

• The first time a built-in command is executed, it loads any needed

support routines into the target-resident memory pool.

• This target server memory pool will be discussed later in the course.


Changing Directories

• Use cd( ) to set WindSh’s working directory (on the

host).

-> cd "/u/team3" (quotes required)

• pwd( ) shows the current working directory.

• Use ls( ) to show contents of the directory.

• These functions are WindSh primitives.

• The shell built-in function cd( ) takes a string argument. If you forget to

quote the path passed to the cd( ) function, a syntax error results:

-> cd /u/team3syntax error->

• Use ioDefPathSet( ) or chdir( ) to change the target’s default path.

• Target-based versions of cd( ), ls( ), and pwd( ) are available in

wind/target/src/usr/usrLib.c.


Downloading via WindSh-> ld (addSyms) < fileName

• Loads object module fileName into the target server’s

memory pool on the target.

• Adds global symbols to host-resident symbol table

(default). If addSyms == 1, load static symbols also.

• Resolves undefined symbols as module is loaded.

• If loader is unable to resolve an external reference, then

ld( ) issues a warning; however the load does not fail

and the loaded module is present on the target.

• Returns ERROR on error, or a nonzero host-based

module ID on success.

• Unloads old version of module if it exists.

• Example:

-> cd (“/u/team N/programs”)-> ld 1 < demo.o

• Unresolved references in loaded modules are NOT retroactively

resolved by later loads. Further, if a module is reloaded and other

modules on the target reference that module, they should be reloaded

also.


WindSh Loading Example-> ld 1 < foo.oLoading /folk/swagon/prog/foo.o |value = 402912 = 0x625e0-> moduleShowMODULE NAME MODULE ID GROUP TEXT START DATA START BSS START----------- ---------- ------- ---------- ---------- ----------vxWorks 0x5b588 1 0x10074 0x9ae90 0xa0228foo.o 0x62878 2 0xd76c0 0xd7930 0xd7bb4value = 0 = 0x0-> fooInit### Warning: Snafu #6. Continuing anyway...value = 0 = 0x0->

...

-> unld "foo.o"value = 0 = 0x0-> moduleShowMODULE NAME MODULE ID GROUP TEXT START DATA START BSS START----------- ---------- ------- ---------- ---------- ----------vxWorks 0x5b588 1 0x10074 0x9ae90 0xa0228value = 0 = 0x0->

• The moduleShow() command lists the modules presently loaded on the

target, their host-based module IDs, group numbers, and the location of

their text, data, and bss segments on the target. (Group numbers are

used in the symbol table to identify which module defined a particular

symbol, so that the symbol may be removed when that module is

unloaded.)

• Currently loaded modules can also be displayed using the Browser,

which also displays the symbols defined by the module.


Function Call Execution

• From WindSh:

• WindSh blocks until demo returns.

• Standard I/O of tN is redirected to WindSh (default).

Host Target

WindSh

-> demo (8)

tN

demo

priority 4

• Task priorities in VxWorks range from 0 (highest) to 255 (lowest). They

will be discussed in a later chapter.

• WindSh will not block on break points. If a function directly called from

the WindSh hits a breakpoint, the shell prints a message saying so, the

shell prompt returns, and the task executing the function is left

suspended at the breakpoint. You may continue it with the c( ) shell

built-in.

• If the called function itself terminates by calling exit( ) (rather than just

returning), WindSh will not be notified that the spawned task has

finished executing. In this case you must type ^C or Ctrl-Break to regain

the shell prompt.

• The standard I/O of the spawned task is redirected to the WindSh by

means of a facility called Virtual I/O (to be discussed).


Spawning tasks with sp()

• As a task:

• WindSh returns immediately after spawning the task

“sMuN”. This task’s I/O is not redirected to the shell.

Host Target

WindSh

->sp (demo,8)

sMuN

demo

priority 100->

• The return value from sp() is the task ID of the spawned task. Task IDs

will be discussed more completely in a later chapter.

• In the task name sMuN, M is a number identifying the shell instance,

and N increments each time sp() is used in this shell.

• Delete tasks with td (taskNameOrId).


The i function

• To display task information:

i (taskNameOrId)

• Example:

-> i (tNetTask) NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY

-------- --------- ------ --- ------- ------ ------- ------ -----

tNetTask _netTask 3e1d28 50 READY 261e4 3e1cc0 0 0

value = 0 = 0x0

• If taskNameOrId = 0, display information for all tasks.

• Use ti( ) for detailed task information.

• To display information about all tasks:

-> i

Recall that the shell passes zeros for any unspecified arguments, andfunction call parentheses are not necessary if the function callconstitutes the whole expression. The above call to the (built-in)function i() illustrates this.

• Analogous task information is available in the Browser.

• By default i( ) gathers task information at several different instants. To

have all of the data collected in a single target transaction, use iStrict( ).

• In the example above, the shell converts tNetTask to a task ID.

Consequently, the i( ) function is passed a task ID, not a task name.


WindSh Assembly Level Debugging• Example:

-> b (printf)-> sp (stuff)task spawned: id = 0x23e0a3c, name = s1u3

value = 37620284 = 0x23e0a3c

Break at 0x2005f78: _printf Task: 0x23e0a3c (s1u3)

-> tt( )20461b8 _vxTaskEntry +10 : _stuff (0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

23feb4a _stuff +12 : _func1 (1)

23febf2 _func1 +18 : _printf (23fec39, 23fec2e)

value = 0 = 0x0

-> cvalue = 0 = 0x0

• If a task halts unexpectedly, tt( ) can be used to find out

what routine failed.

• Use CrossWind for full source-level debugging.

• The output from tt( ):

● The value on the left is the address of the current position in thesubroutine.

● The + value after the function name is offset from the beginning ofthe subroutine (in hexadecimal).

● A hexadecimal dump of the subroutine arguments is shown.

• Function Meaning

b set breakpoint/list breakpoints.bd delete a breakpointbdall delete all breakpointss single stepl disassemble codett stack tracec resume execution from breakpoint


Tcl and WindSh Customization

• Tcl is a powerful scripting language which:

● Is interpreted

● Allows commands to take arguments

● Has standard flow-control structures

● Has powerful string manipulation facilities

• To toggle between WindSh’s C and Tcl modes, enter ‘?’

at the prompt:

-> ?tcl> proc myCmd {...} {...}

• To run a single Tcl command from WindSh, preface the

command with a ‘?’:

-> ?myCmd

• Add Tcl extensions in windsh.tcl.

• WindSh automatically executes a Tcl script (windsh.tcl) on start-up.

● In UNIX environments, windsh.tcl is executed if it is found in thedirectory $HOME/.wind/.

● Under Windows, windsh.tcl is searched for in two directories: first inc:\Tornado\.wind\ (assuming c:\Tornado\ is the Tornadoinstallation directory), then in %HOME%\.wind\ (if theenvironment variable %HOME% is defined). In each directory, if thefile exists, the WindSh Tcl interpreter executes it.

• Use the command shParse to get the C interpreter to execute an

expression from the Tcl interpreter. For example:

tcl> shParse {printf (“Tcl is amazing!\n”)}

passes the string ‘printf (“Tcl is amazing!\n”) ’ to the C interpreter.


Shell Configuration Variables

• The WindSh has a few configuration variables which

govern some aspects of its operation.

-> ?shConfigDSM_HEX_MODE = offLD_CALL_XTORS = targetLD_COMMON_MATCH_ALL = onLD_PATH = .LD_SEND_MODULES = onSH_GET_TASK_IO = on->

The above are the default values.

• To change a value:

-> ?shConfig SH_GET_TASK_IO off->

• LD_PATH may be set to a list of directories (separated by semicolons) to

be searched for object modules when loading from the shell. If

LD_SEND_MODULES is on, the shell sends the target server the whole

module it wants loaded, rather than just its filename. When

LD_COMMON_MATCH_ALL is on, common symbols in a module

loaded from WindSh will match common symbols already on the target

(this is required for some C++ programs). LD_CALL_XTORS governs

whether C++ contructors for statically allocated objects are called

automatically when a module is loaded by WindSh. Besides on or off,this variable may be target; if so, the target’s strategy (set by

cplusXtorSet()) governs whether the constructors are called.

• If SH_GET_TASK_IO is on, the standard input and output of tasks

spawned by the shell to execute function calls will be redirected to the

WindSh window using virtual I/O.


Virtual I/O

• By default, a target’s standard input, output, and error

are directed to the console used to set boot parameters.

• Use Virtual I/O to associate the target’s input/output

with a Virtual Console.

• Once a Virtual I/O channel is opened, it behaves like a

normal character (stream) I/O device.

• Useful if target lacks an serial I/O channel, or if

developing remotely.

• Click the Virtual Console and Target I/O Redirectcheckboxes when configuring the target server.

• Data is transferred via the target server - WDB agent connection.

• To manually redirect a target’s global standard I/O to Virtual I/O

channel 0 (if you checked Virtual Console, but not Target I/O Redirect)modify windsh.tcl:

if { [shParse {vf0 = open (“/vio/0”,2,0)}] != -1 } {

shParse {ioGlobalStdSet (0,vf0)} ;



shParse {logFdAdd (vf0)} ;

}

• For more information on the workings of Virtual I/O, see the TornadoAPI Guide.


Shell Host I/O Redirection

• Shell input can be redirected to come from a file.

-> < script

• Shell output can be redirected to a file.

-> h( ) > hfile

• Caveat: I/O can only be redirected to files accessible to

the WindSh process running on the development host,

not to local devices on the target!

• File names after a shell redirection symbol ( < or > ) are not quoted.

• You may have to enclose expressions involving the relational < and >

operators in parentheses so the shell does not consider them to be I/O

redirections.

• When redirecting input to the shell from a script, or when cutting and

pasting multiple lines into the WindSh, SH_GET_TASK_IO should be off.


Target-resident Tools

• Target-resident tools are available:

● loadLib Dynamic module loading.

● unldLib Dynamic module unloading.

● shellLib Target-resident C interpreter.

● usrLib Useful utilities like cd, copy, etc.

● dbgLib Native debug library.

• The tools require a target-resident symbol table.

• Caveats:

● These tools consume target resources (RAM).

● Be cautious using these tools in conjunction withTornado host-based tools!

• See the manuals for details.

• Target-resident tools can be useful for field testing and debugging.

• Target-resident show routines are also available to examine object

information.

• Do not use the target-resident shell as a user interface: it has all of the

power of WindSh’s C-expression interpreter. Consequently, it would

allow the naive user to damage your application.


Symbol Table Synchronization

• When using both host-based and target-based tools, the

host and target symbol tables can become inconsistent.

• To prevent this, enable symbol table synchronization:

● Include the component development tool components >symbol table components > synchronize host and targetsymbol tables in VxWorks.

● Launch the target server with the -s option

• The task tSymSync is spawned. It does the following:

● Makes modules or symbols loaded on target beforetarget server attached visible to target server.

● When host symbol table changed, updates the targetsymbol table; when target symbol table changed,informs the target server.

• tSymSync is spawned (with priority 90) when the target server connects

to the target.

• tSymSync attaches to the target server as a WTX tool. This requires

networking support on the target.

• Other symbol table changes, for instance those resulting from creation

of variables in the shell, are also synchronized.

• Neither the target nor the host module loaders wait for synchronization

to complete before returning. The target server generates a SYNC_DONE

event after synchronization completes; if started with the -v option, it

also prints a message indicating synchronization has completed to the

target server log.

• See symSyncLib for more information.


WindSh and Browser

WindSh

3.2 Browser


Browser Overview

• Graphical tool for displaying target information:

● Loaded object modules

● Tasks

● Memory and stack usage

● Interrupt vector table

● VxWorks objects such as semaphores, messagequeues, and watchdog timers

● CPU utilization

• Information is updated on demand or periodically.

• Invoke Browser from

● launcher’s application panel (UNIX)

● launch toolbar or the Tools menu (Windows)

• Put Tcl customizations for the Browser in browser.tcl.

• Use Tcl to customize the GUI or add new functionality.

• See Tornado API Guide for more information on tool customization.

• Caveat: Do not run the Browser in periodic update mode over low-

bandwidth communication channels. Excessive traffic may be

generated as the browser periodically samples the state of objects on the

target. In such environments, request Browser updates on demand.

• The browser can also be invoked from the command line with the

browser function.


UNIX: The Browser

Button Bar

System Tasks

User Tasks

Object DisplaySelection

MemoryConsumption

LoadedModules

• The main Browser window displays (from top to bottom):

● WRS system tasks

● User tasks

● Show box for displaying VxWorks objects.

● Agent Pool memory usage (memory used by Tornado tools)

● VxWorks and application memory usage

● Module information

• Use the control icons in the Button Bar. From left to right:

● Force update of browsed objects.

● Enable periodic updates of browsed objects.

● Check tasks’ stack usage.

● Display interrupt vector table.

● Enable periodic CPU utilization reports (spy).

● Configure the Browser (set update rates, etc.).


PC: The Browser

Browser DisplaySelector

DataPanel

• The Browser Display Selector allows access to displays for:

● Target memory usage by Tornado tools and VxWorks/applications.

● Information on loaded modules.

● Information on VxWorks system objects.

● Spy CPU utilization facility.

● Stack Check.

● Target Information.

● User application and System tasks.

● Interrupt vector table.

• Displays appear in the Data Panel.

• Use the control icons to:

● Force update of browsed objects.

● Enable periodic updates of browsed objects.

● Configure the Browser, setting update rates, etc..


Browser: Examining Objects

SemaphoreDisplay

Message

DisplayQueue

• This example displays information about two VxWorks objects: a

semaphore and a message queue.

• To browse an object, just enter its name or object ID in the dialog box

next to the Show button.

• Alternatively, you can browse objects from WindSh:

-> browse semId

Then the Browser will display the object’s information the next time itupdates its display.


Timing Overview

• Browser’s spy facility

● Activity profiler (% CPU utilization per task).

● Uses the auxiliary clock.

• timexLib

● Subroutine timer.

● Uses the system clock.

• WindView

● Uses instrumented kernel and high-resolution timerdrivers to capture precise event data.

● Intuitive GUI for analyzing data.

● Discussed in chapter 7.


Browser’s Activity Profiler

Configure Spy’s sampling with theBrowser configuration button

● Browser update time /Spy report time.

● Spy collection frequency.

● Spy mode: differential orcumulative


Subroutine Timer

timex (func, args) Times single execution of func.

timexN (func, args) Repeats execution to obtainaccurate timing.

• Example:

-> timex (stuff, "The answer is", 42)timex: execution time too short to be measuredmeaningfully in a single execution.

Type “timexN” to time repeated execution. Type “timexHelp” for more information.

value = 46 = 0x2e = ‘.’-> timexN (stuff, "The answer is", 42)timex: 50 reps, time per rep = 50293 +/- 333 (0%)microsecs

• Additional routines can be found in timexLib:

timexFunc (i, func, args) Allows timing up to four functions; addsfunction to array used by timex and timexN: iindicates the position in the array.

timexShow( ) Displays the current list of functions to becalled.

Call timex( ) or timexN( ) with NULL parameter to execute functions inthe timex array.


Summary

• WindSh is a C and Tcl interpreter shell for accessing the

target.

• Tools for managing target-resident object modules:

ld unld moduleShow

• Tools for starting/stopping a thread of execution:

sp td

• Tools for debugging from WindSh:

i lkup

l tt


Summary

• Use the Browser to:

● Display system information.

● Examine objects.

● Display CPU utilization.

• Performance monitoring tools:

timex timexN

spy

windsh and browserread.pudn.com/downloads20/sourcecode/embed/68037/tornado tr… · the target from...

Documents