Warning, /testsuites/samples/capture/capture.doc is written in an unsupported language. File is not indexed.
0001 # SPDX-License-Identifier: BSD-2-Clause
0002
0003 # COPYRIGHT (c) 1989-1999.
0004 # On-Line Applications Research Corporation (OAR).
0005 #
0006 # Redistribution and use in source and binary forms, with or without
0007 # modification, are permitted provided that the following conditions
0008 # are met:
0009 # 1. Redistributions of source code must retain the above copyright
0010 # notice, this list of conditions and the following disclaimer.
0011 # 2. Redistributions in binary form must reproduce the above copyright
0012 # notice, this list of conditions and the following disclaimer in the
0013 # documentation and/or other materials provided with the distribution.
0014 #
0015 # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
0016 # AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
0017 # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
0018 # ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
0019 # LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
0020 # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
0021 # SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
0022 # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
0023 # CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
0024 # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
0025 # POSSIBILITY OF SUCH DAMAGE.
0026 #
0027
0028 Capture Engine Tutorial
0029
0030 The Capture Engine is a software trace tool built into the RTEMS operating
0031 system. Being software it does use CPU and memory resources. If do not use it
0032 does not effect RTEMS or your application. The Capture Engine is designed to
0033 placed the lowest load possible on the system when operating and when disabled
0034 does not effect RTEMS. It binds to RTEMS at runtime and does not require RTEMS
0035 or your application to be rebuilt inorder to use it.
0036
0037 This tutorial will guide you through the building of RTEMS and the sample
0038 programs for the pc586 BSP on Windows using the MinGW tools. The RTEMS Capture
0039 Engine sample programmes are found in CVS and will be available in the next
0040 release of RTEMS. The turoial will show how to create filters and triggers and
0041 how to obtain a trace of the tasks running. The Capture Engine Command Line
0042 Interface (CLI) will be used as this currently is the only available interface
0043 to the Capture Engine.
0044
0045 The tutorial uses the PC586 BSP running under QEMU. This provides a stable
0046 environment that be easly duplicated on readly available hardware. If you are
0047 new to RTEMS, simulators helps you get RTEMS running quickly. The RTEMS Wiki
0048 provides the information needed to download and install these tools.
0049
0050 In this tutorial I have placed the RTEMS source code into the Windows
0051 directory:
0052
0053 c:\rtems\src\rtems-4.7.0
0054
0055 RTEMS is configured using the shell MSYS with this command:
0056
0057 $ /c/rtems/src
0058 $ mkdir pc586
0059 $ cd pc586
0060 $ /c/rtems/src/rtems-4.7.0/configure --target=i386-rtems4.8 \
0061 --enable-network --enable-posix --enable-cxx\
0062 --enable-tests=samples --enable-maintainer-mode \
0063 --enable-rtemsbsp=pc586
0064 $ make all
0065
0066 If you wish to use the Windows Command prompt open an RTEMS Command prompt
0067 window by running the c:\rtems\i386\rtems-cmd.bat batch file from Explorer. The
0068 shell commands become:
0069
0070 RTEMS(i386) C:\rtems\i386> cd ..\src
0071 RTEMS(i386) C:\rtems\src> mkdir pc586
0072 RTEMS(i386) C:\rtems\src> cd pc586
0073 RTEMS(i386) C:\rtems\src\pc586> sh /c/rtems/src/rtems-4.7.0/configure
0074 --target=i386-rtems4.7 --enable-network --enable-posix
0075 --enable-tests=samples --enable-maintainer-mode --enable-cxx
0076 --enable-rtems-bsp=pc586
0077 RTEMS(i386) C:\rtems\src\pc586> make all
0078
0079 Install the Windows version of QEMU and run with the following command:
0080
0081 RTEMS(i386) C:\rtems\src\pc586> type c:\rtems\i386\bin\qemu.bat
0082 rem @echo off
0083 set QEMU=C:\rtems\i386\qemu-0.8.2-windows
0084 %QEMU%\qemu -L %QEMU% -m 128 -boot a -fda c:\rtems\i386\rtems-boot.img
0085 -hda fat:%1 %2 %3
0086
0087 You will need to download the GRUB boot loader image from the RTEMS
0088 website. This image will boot the QEMU PC and attempt to read a GRUB
0089 configuration file from the hda root directory. You pass the qemu.bat file the
0090 path on your disk to the hda root directory. The capture engine examples are in
0091 the standard testsuite examples directory. For our Windows host once built they
0092 are in:
0093
0094 rtems\src\pc586\i386-rtems4.8\c\pc586\testsuites\samples
0095
0096 In this directory create a GRUB configuration file with an entry similar to
0097 this one:
0098
0099 RTEMS(i386) C:\rtems\src\pc586> type i386-rtems4.8\c\pc586\testsuites\sam
0100 ples\rtems-grub.cfg
0101 # RTEMS Grub configuration for the Samples
0102 set default=0
0103
0104 menuentry "RTEMS - Capture" {
0105 set root=(hd0,0)
0106 multiboot (hd0,0)/capture/capture.exe
0107 }
0108
0109 It has a single entry the Capture Engine test. Change to the samples directory
0110 and run QEMU using the QEMU batch file we created above:
0111
0112 RTEMS(i386) C:\rtems\src\pc586> cd i386-rtems4.7\c\pc586\testsuites\samples
0113 RTEMS(i386) C:\rtems\src\pc586\i386-rtems4.7\c\pc586\testsuites\samples> qemu .
0114
0115 A QEMU console will open and you will see the GNU GRUB menu. The "RTEM -
0116 Capture" menu item will be highlighted. Press Enter and GRUB will load and
0117 execute the RTEMS Capture Engine example.
0118
0119 RTEMS will only take a moment to initialise and you will be presented with the
0120 RTEMS monitor login prompt:
0121
0122 Initialized console on port CONSOLE
0123
0124
0125 *** CAPTURE ENGING TEST ***
0126
0127 Monitor ready, press enter to login.
0128
0129 rtems $
0130
0131 The standard configuration is the Capture Engine not initialised and not
0132 running. It needs to be initialised. You enter a trace buffer size in bytes
0133 with the open command:
0134
0135 rtems $ copen 5000
0136 capture engine open
0137 rtems $
0138
0139 If you look in the Capture Engine example source code 'test1.c' a CLI command
0140 'test1' is added to the RTEMS monitor. When you enter the 'test1' command the
0141 'RMON' task will call 'capture_test_1()'. This function creates a task called
0142 'CT1a' and starts it, then task 'CT1b' is created and started and finally
0143 'CT1c' is created and started. All tasks are passed the object id of a
0144 semaphore as a task argument. The RMON command thread then loops sleeping for 1
0145 second, waking to check if all of the tasks that have been created have been
0146 deleted themselves. Once all tasks have been deleted the command returns
0147 presenting the prompt to the user.
0148
0149 The first task started is 'CT1a'. It obtains the mutex, waits 2.5 seconds,
0150 releases it then deletes itself. The second task 'CT1b' loops until task 'CT1c'
0151 has been deleted. The last task 'CT1c' also obtains the semaphore, waits 0.5
0152 seconds, releases the semaphore then deletes itself.
0153
0154 The priority of RMON is 1 and is the highest priority task. The task 'CT1a' has
0155 the lowest priority of 102, task 'CT1b' has a priority of 101, and 'CT1c' is the
0156 highest priority of the three created tasks with 100.
0157
0158 The test generates priority inheritance where task 'CT1a' inherits the priority
0159 of task 'CT1c' and the Capture Engine captures this for you to observe. Task
0160 'CT1a' obtains the semaphore with a priority of 102 then sleeps. Task 'CT1b'
0161 consumes all of the CPU time with a priority of 101. Normally task 'CT1a' would
0162 never run again. Task 'CT1c' runs and blocks waiting for the semaphore. When
0163 task 'CT1a' wakes after 2.5 seconds it inherits the priority of task 'CT1c'
0164 which is 100, higher than task 'CT1b'. Task 'CT1a' can now run and releases the
0165 semaphore which task 'CT1c' obtains. After it wakes from a 0.5 second sleep it
0166 releases the semaphore and deletes itself which causes task 'CT1b' to delete
0167 itself.
0168
0169 We could just open the capture engine, enable it and start tracing how-ever
0170 there could be a large number of context switches before we get to our test and
0171 the tasks events we are interested in. This would create a large amount of
0172 trace noise and add extra load onto the system capturing this noise. A software
0173 capture tool like this one is effective if we can filter the events recorded
0174 into the trace buffer and if we can control when we trigger to start
0175 recording.
0176
0177 The simplest type of filter is the ceiling and floor priority filter. Here we
0178 narrow the range of priorities captured. This is useful for applications which
0179 typically have a middle range of priorites removing device type tasks such as
0180 networking tasks or file system tasks as well as low priority back ground
0181 tasks. Our test tasks have a priority range of 100 to 102. The filter is set
0182 with the following commands:
0183
0184 rtems $ cwceil 100
0185 watch ceiling 100.
0186 rtems $ cwfloor 102
0187 watch floor is 102.
0188 rtems $
0189
0190 We also need to enable the global watch. This causes all tasks in the priority
0191 range to be captured:
0192
0193 rtems $ cwglob on
0194 global watch enabled.
0195 rtems $
0196
0197 You can set or clear a trigger. To start with we will use the simplest trigger
0198 we can have. This is just a task name. As the RMON task handles the RTEMS
0199 monitor keyboard and executes the commands we shall trigger when this task
0200 effects a task in our priority range. To set the trigger use this command:
0201
0202 rtems $ ctset RMON
0203 trigger set.
0204 rtems $ cwlist
0205 watch priority ceiling is 100
0206 watch priority floor is 102
0207 global watch is enabled
0208 total 1
0209 00000000 RMON g- T:S------ F:-----
0210 rtems $
0211
0212 The 'cwlist' command lists the watch and trigger configuration. You will see
0213 the RMON trigger line has a number, a label and flags. Later you will be given
0214 more detail on these values. The number is an RTEMS object id. It is 0 which
0215 means use the label when looking for the trigger. We could have entered the
0216 task id for RMON in the trigger rather than the label.
0217
0218 The capture engine is disabled after being opened and needs to be enabled. The
0219 ability to enable and disable the capture engine with a single command allows
0220 you to remove any effect the capture may have on the application while you are
0221 tracing a problem. To enable enter:
0222
0223 rtems $ cenable
0224 capture engine enabled.
0225 rtems $
0226
0227 To dump a recorded the trace you enter:
0228
0229 rtems $ ctrace
0230 rtems $
0231
0232 The trace buffer is empty. Notice how the capture engine is not triggering on
0233 the RMON task or the execution of any other tasks that may be in the
0234 system. Every monitor key press causes the RMON task to be switched in to
0235 run. It is now time to run the test so enter the 'test1' command:
0236
0237 rtems $ test1
0238 rtems $
0239
0240 After a few seconds the RTEMS monitor prompt will return and we can dump the
0241 trace.
0242
0243 rtems $ ctrace
0244 91.980000 0a010002 RMON 1 1 CREATED_BY
0245 91.980000 0a010003 CT1a 102 102 CREATED
0246 91.980000 0a010002 RMON 1 1 STARTED_BY
0247 91.980000 0a010003 CT1a 102 102 STARTED
0248 91.980000 0a010003 CT1a 102 102 SWITCHED_IN
0249 91.980000 0a010003 CT1a 102 102 BEGIN
0250 91.980000 0a010003 CT1a 102 102 SWITCHED_OUT
0251 92.980000 0a010002 RMON 1 1 CREATED_BY
0252 92.980000 0a010004 CT1b 101 101 CREATED
0253 92.980000 0a010002 RMON 1 1 STARTED_BY
0254 92.980000 0a010004 CT1b 101 101 STARTED
0255 92.980000 0a010004 CT1b 101 101 SWITCHED_IN
0256 92.980000 0a010004 CT1b 101 101 BEGIN
0257 93.980000 0a010004 CT1b 101 101 SWITCHED_OUT
0258 93.980000 0a010002 RMON 1 1 CREATED_BY
0259 93.980000 0a010004 CT1c 100 100 CREATED
0260 93.980000 0a010002 RMON 1 1 STARTED_BY
0261 93.980000 0a010005 CT1c 100 100 STARTED
0262 93.980000 0a010005 CT1c 100 100 SWITCHED_IN
0263 93.980000 0a010005 CT1c 100 100 BEGIN
0264 93.980000 0a010005 CT1c 100 100 SWITCHED_OUT
0265 93.980000 0a010004 CT1b 101 101 SWITCHED_IN
0266 rtems $
0267
0268 The trace dump command by default displays 24 trace records. We have more so
0269 enter the trace command until all have been displayed. The details of the trace
0270 data will be discussed once we have all the trace data.
0271
0272 rtems $ ctrace
0273 94.480000 0a010004 CT1b 101 101 SWITCHED_OUT
0274 94.480000 0a010003 CT1a 102 100 SWITCHED_IN
0275 94.480000 0a010003 CT1a 102 102 SWITCHED_OUT
0276 94.480000 0a010005 CT1c 100 100 SWITCHED_IN
0277 94.480000 0a010005 CT1c 100 100 SWITCHED_OUT
0278 94.480000 0a010004 CT1b 101 101 SWITCHED_IN
0279 94.980000 0a010004 CT1b 101 101 SWITCHED_OUT
0280 94.980000 0a010005 CT1c 100 100 SWITCHED_IN
0281 94.980000 0a010005 CT1c 100 100 DETELED_BY
0282 94.980000 0a010005 CT1c 100 100 DETELED
0283 94.980000 0a010004 CT1b 101 101 SWITCHED_IN
0284 94.980000 0a010004 CT1b 101 101 DELETED_BY
0285 94.980000 0a010004 CT1b 101 101 DELETED
0286 94.980000 0a010003 CT1a 102 100 SWITCHED_IN
0287 94.980000 0a010003 CT1a 102 100 DELETED_BY
0288 94.980000 0a010003 CT1a 102 100 DELETED
0289 rtems $
0290
0291 The first column of the trace data is the time stamp. The test command started
0292 when the time stamp was 91.98 seconds and took 3 seconds to run. Your trace
0293 will have a different starting value but the total time should be 3
0294 seconds. The actual start value is the time it takes you to enter the various
0295 capture commands. It would seem I am rather slow.
0296
0297 The second column is the object id. In this case they are task ids. The third
0298 column is the object name.
0299
0300 The fourth is the real task priority and fifth column is the executing task
0301 priority. The executing priority follows any priority inheritance. The last
0302 column is the event the capture engine has captured.
0303
0304 The first couple of records:
0305
0306 91.980000 0a010002 RMON 1 1 CREATED_BY
0307 91.980000 0a010003 CT1a 102 102 CREATED
0308
0309 show at 91.98 seconds task id '0a010002' named 'RMON' with a priority of 1 and
0310 executing at a priority of 1 created task id '0a010003' named 'CT1a' with a
0311 priority of 102 and an executing priority of 102. Next 'RMON' started 'CT1a'
0312 and it was switch into context, began running, then was switched out.
0313
0314 91.980000 0a010002 RMON 1 1 STARTED_BY
0315 91.980000 0a010003 CT1a 102 102 STARTED
0316 91.980000 0a010003 CT1a 102 102 SWITCHED_IN
0317 91.980000 0a010003 CT1a 102 102 BEGIN
0318 91.980000 0a010003 CT1a 102 102 SWITCHED_OUT
0319
0320 The task 'CT1a' was switched out because it blocked on the semaphore.
0321
0322 If you look at the 'test1' command's code you will see the command sleeps for 1
0323 second after starting the task. This is why the lower priority task 'CT1a' is
0324 switched in and able to run. The sleep can be seen in the next event where
0325 'RMON' creates 'CT1b'. The timestamp is 1 second later.
0326
0327 92.980000 0a010002 RMON 1 1 CREATED_BY
0328 92.980000 0a010004 CT1b 101 101 CREATED
0329 92.980000 0a010002 RMON 1 1 STARTED_BY
0330 92.980000 0a010004 CT1b 101 101 STARTED
0331 92.980000 0a010004 CT1b 101 101 SWITCHED_IN
0332 92.980000 0a010004 CT1b 101 101 BEGIN
0333 93.980000 0a010004 CT1b 101 101 SWITCHED_OUT
0334
0335 There are no 'RMON' switched in or switched out events. These are being
0336 filtered by the priority range filter. We see the 'RMON' CREATED_BY events as
0337 these are actually occuring on test tasks which are in the priority range.
0338
0339 The create and start process is repeated for the remaining two tasks. The
0340 following section of the trace show 'CT1c' being switch out and 'CT1b' being
0341 switch in. Task 'CT1b' loops consuming all of the CPU time until 'CT1a'
0342 wakes. This is 500 milli-seconds.
0343
0344 93.980000 0a010005 CT1c 100 100 BEGIN
0345 93.980000 0a010005 CT1c 100 100 SWITCHED_OUT
0346 93.980000 0a010004 CT1b 101 101 SWITCHED_IN
0347 94.480000 0a010004 CT1b 101 101 SWITCHED_OUT
0348 94.480000 0a010003 CT1a 102 100 SWITCHED_IN
0349
0350 When 'CT1a' wakes it is executing at the priority of 'CT1c' of 100 and so
0351 higher than 'CT1b'. Task 'CT1a' then releases the semaphore dropping it
0352 priority back to 102 allowing 'CT1c' to run.
0353
0354 94.480000 0a010003 CT1a 102 102 SWITCHED_OUT
0355 94.480000 0a010005 CT1c 100 100 SWITCHED_IN
0356 94.480000 0a010005 CT1c 100 100 SWITCHED_OUT
0357 94.480000 0a010004 CT1b 101 101 SWITCHED_IN
0358 94.980000 0a010004 CT1b 101 101 SWITCHED_OUT
0359 94.980000 0a010005 CT1c 100 100 SWITCHED_IN
0360
0361 Task 'CT1c' release the semaphore and deletes itself. Task 'CT1b' is switched
0362 in and it is looping waiting for 'CT1c' to delete. This has happen so 'CT1b'
0363 deletes itself. Finally 'CT1a' deletes itself.
0364
0365 94.980000 0a010005 CT1c 100 100 DETELED_BY
0366 94.980000 0a010005 CT1c 100 100 DETELED
0367 94.980000 0a010004 CT1b 101 101 SWITCHED_IN
0368 94.980000 0a010004 CT1b 101 101 DELETED_BY
0369 94.980000 0a010004 CT1b 101 101 DELETED
0370 94.980000 0a010003 CT1a 102 100 SWITCHED_IN
0371 94.980000 0a010003 CT1a 102 100 DELETED_BY
0372 94.980000 0a010003 CT1a 102 100 DELETED
0373
0374 The delete event shows the task deleting itself as the DELETED_BY event is the
0375 same as the DELETED event.
0376
0377 We will now explore some more complex filters and triggers. First close the
0378 QEMU window and start QEMU again and open and enable the capture engine:
0379
0380 rtems $ copen 5000
0381 capture engine open
0382 rtems $ cenable
0383 capture engine enabled.
0384 rtems $
0385
0386 In this example we only want to monitor task 'CT1c' and wish to trigger on a
0387 context switch from 'CT1c' to 'CT1a'. This happens when 'CT1a' releases the
0388 semaphore and CT1c claims it. The set up is:
0389
0390 rtems $ cwadd CT1c
0391 watch added.
0392 rtems $ cwctl CT1c on
0393 watch enabled.
0394 rtems $ ctset switch CT1c from CT1a
0395 trigger set.
0396 rtems $ cwlist
0397 watch priority ceiling is 0
0398 watch priority floor is 0
0399 global watch is disabled
0400 total 1
0401 00000000 CT1c -w T:------- F:-----
0402 0:CT1a/00000000:S----
0403 rtems $
0404
0405 We run the test and capture the output:
0406
0407 rtems $ test1
0408 rtems $ ctrace
0409 61.150000 0a010005 CT1c 100 100 SWITCHED_IN
0410 61.150000 0a010005 CT1c 100 100 SWITCHED_OUT
0411 61.650000 0a010005 CT1c 100 100 SWITCHED_IN
0412 61.650000 0a010005 CT1c 100 100 DELETED_BY
0413 61.650000 0a010005 CT1c 100 100 DELETED
0414 rtems $
0415
0416 The trace shows CT1c being switched in once it has the semaphore then switching
0417 out while it waits 500 milli-seconds, waking and being switched in to delete
0418 itself. The filtering means we can focus on the specific events which we are
0419 interested in and the trigger means we only trace once the specific event we
0420 are interested in occurs.
0421
0422 The filter and trigger do not need to relate. Lets run a variation of the last
0423 configuation where we watch 'CT1b' and trigger on 'CT1c' being switched to from
0424 'CT1a'. Close the QEMU window and start QEMU again and open and enable the
0425 capture engine:
0426
0427 rtems $ copen 5000
0428 capture engine open
0429 rtems $ cenable
0430 capture engine enabled.
0431 rtems $ cwadd CT1b
0432 watch added.
0433 rtems $ cwctl CT1b on
0434 watch enabled.
0435 rtems $ ctset switch CT1c from CT1a
0436 trigger set.
0437 rtems $ cwlist
0438 watch priority ceiling is 0
0439 watch priority floor is 0
0440 global watch is disabled
0441 total 2
0442 00000000 CT1c -- T:------- F:-----
0443 0:CT1a/00000000:S----
0444 00000000 CT1b -w T:------- F:-----
0445 rtems $
0446
0447 You can see 2 watch controls exist, one for the trigger and one for the filter.
0448 Before we run the test we will take a look at the task list using the 'ctlist'.
0449
0450 rtems $ ctlist
0451 total 2
0452 09010001 IDLE 255 255 255 READY a--- 0% 0% (10682)
0453 0a010002 RMON 1 1 1 READY a--- 0% 0% (826)
0454 rtems $
0455
0456 You can see the 2 tasks that are active. These tasks existed before the capture
0457 engine started. The capture engine learns about tasks that exist in a system if
0458 they do something. If a task exists and does nothing the capture engine will
0459 not know about it. Lets run the test then list the tasks again:
0460
0461 rtems $ test1
0462 rtems $ ctlist
0463 total 3
0464 0a010004 CT1b 101 0 0 READY dtw- 100% 0% (200)
0465 09010001 IDLE 255 255 255 READY a--- 0% 0% (10682)
0466 0a010002 RMON 1 1 1 READY a--- 0% 0% (826)
0467 rtems $
0468
0469 This time the task lists the test task we are watching 'CT1b'. If how-ever has
0470 been deleted and the task list shows this with the 'd' in the flags. The active
0471 tasks have an 'a'. The capture engine has to retain information on tasks that
0472 have been deleted so the trace data can be generated. The trace buffer holds a
0473 reference to the task's details not the specific details. Once the trace data
0474 has been viewed the task data is no longer needed and released.
0475
0476 rtems $ ctrace
0477 551.630000 0a010004 CT1b 101 101 SWITCHED_IN
0478 552.130000 0a010004 CT1b 101 101 SWITCHED_OUT
0479 552.130000 0a010004 CT1b 101 101 SWITCHED_IN
0480 552.130000 0a010004 CT1b 101 101 DELETED_BY
0481 552.130000 0a010004 CT1b 101 101 DELETED
0482 rtems $ ctlist
0483 total 2
0484 09010001 IDLE 255 255 255 READY a--- 0% 0% (10682)
0485 0a010002 RMON 1 1 1 READY a--- 0% 0% (826)
0486 rtems $
0487
0488 Listing the tasks shows 'CT1b' has gone. The trace buffer does not reference
0489 it any more.
0490
0491 We have now seen the following capture commands:
0492
0493 copen
0494 cenable
0495 ctlist
0496 cwceil
0497 cwfloor
0498 cwglob
0499 cwadd
0500 cwctl
0501 ctset
0502 ctrace
0503
0504 The ctset is worth a closer look. The general form of the command is:
0505
0506 ctset [-?] type [to name/id] [from] [from name/id]
0507
0508 The 'type' is the type of trigger. The following possible types of triggers
0509 exist:
0510
0511 switch - a context switch from one task to another task
0512 create - the executing task creates a task
0513 start - the executing task starts a task
0514 restart - the executing task restarts a task
0515 delete - the executing task deletes a task
0516 begin - a task is beginning
0517 exitted - a task is exitting
0518
0519 With the ctset command you set a trigger for a task. If you do not supply a
0520 from task the type of event can be from any task. You can be more specific by
0521 stating the event for a task must be by a specific task. Looking at the examples
0522 from before we set a trigger on a context switch from CT1a to CT1c with:
0523
0524 ctset switch CT1c from CT1a
