Getting Started

Introduction

WRDBG is the Wind River DeBuG shell. While the WRDBG command syntax is compatible with GDB when possible, it is not intended to be a fully compatible GDB shell.

Because this debug shell is intended for connections to Wind River debug agents, it adds some commands which are not available with GDB (such as target connection commands).

The debug shell is available from the Workbench UI and from the command line.

Workbench Debug Shell View vs. Headless Mode

WRDBG from Workbench and from the command line share capabilities such as a line completion, a line history, and so on. They also share almost the same set of commands. However, there are some differences (see below).

As with GDB, the debug shell has an internal help mechanism, which is accessed using the command help:

(wrdbg) help

List of classes of commands:

aliases -- Aliases of other commands
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
status -- Status inquiries
support -- Support facilities

Type "help" followed by a class name for a list of commands in that class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Command name abbreviations are allowed if unambiguous.

If a given command is not available for the current connection, its help is available, but it mentions that the command is not enabled

(wrdbg) help module load
Load a module.

Usage: module load FILE

- FILE is the path of the module file to load on target.

See "help module" for a full description of what "FILE" stands for.

Some options can be specified when loading a module.

See "help set module load" for a full description of load options.

NOTE: Command is not enabled: The required service "WR_Module" is not available for the "vxworks7-coredump" connection.

Line Completion

The debug shell supports line completion using the [TAB] key. The kind of completion used is context sensitive, that is, it depends on what was typed before. The shell can complete a line of shell commands, aliases, shell variable names, command options, and arguments.

For example, for the command file, which takes a file pathname as an argument, the shell will try to complete the file pathname. If a non-ambiguous pathname is found, it is defined as the file argument. Otherwise, a second hit of the [TAB] key will propose a list of all possibilities. The same mechanism exists for the other commands.

(wrdbg) fil[TAB]
(wrdbg) file /folk/use[TAB]
(wrdbg) file /folk/user/[TAB]
(wrdbg) file /folk/user/[TAB][TAB]
/folk/user/foo                      /folk/user/bar          /folk/user/dummy_foo
/folk/user/dummy_bar
(wrdbg) file /folk/user/du[TAB]
(wrdbg) file /folk/user/dummy_[TAB]
(wrdbg) file /folk/user/dummy_[TAB][TAB]
/folk/user/dummy_foo /folk/user/dummy_bar
(wrdbg) file /folk/user/dummy_f[TAB]
(wrdbg) file /folk/user/dummy_foo

Line History

The debug shell supports line history differently from Workbench or from the command line (see below). However, for both versions, the line history is accessed using the [UP] and [DOWN] arrow keys. The line from the history can be edited again and, when entered, it will create a new entry at the end of the history.

Sourcing an External Script

It is possible to source (execute) a set of WRDBG commands from an external script using the source command:

(wrdbg) help source
Read commands from a file named FILE.

Usage: source [-v] FILE
-v: each command in FILE is echoed as it is executed.

Note that the file "$HOME/.wrdbg/rc" is read automatically in this way
when WRDBG is started.

Aliases

It is possible to define command aliases using the command alias:

(wrdbg) help alias
Define a new command that is an alias of an existing command.
Usage: alias [-a] [--] ALIAS = COMMAND
ALIAS is the name of the alias command to create.
COMMAND is the command being aliased to.
If "-a" is specified, the command is an abbreviation,
and will not appear in help command list output.

Examples:
Make "spe" an alias of "set print elements":
alias spe = set print elements
Make "elms" an alias of "elements" in the "set print" command:
alias -a set print elms = set print elements

WRDBG already defines several aliases. Use the command help aliases (when connected to a target) to get the list of aliases.

Format of File Pathnames

The WRDBG commands that are used to load an object file to the target (for example, kernel modules and RTPs for VxWorks) accept a host file pathname or a target file pathname.

A host file is a file that can be accessed by WRDBG through file system calls. File pathname may be a relative or an absolute pathname. It may be specified using forward slash (/) notation, even on Windows host.

A target file pathname must be prepended with the target: prefix. In this case the target file system is accessed. Target file pathnames must use the forward slash (/) notation.

If the file path contains a space character, the whole file pathname must be enclosed by double quotes.

file target:/romfs/myrtp.vxe
file C:\\temp\\myrtp.vxe
file C:/temp/myrtp.vxe
file "C:\\my dir\\my rtp.vxe"
file target:"/my dir/my rtp.vxe"

WRDBG from Workbench

WRDBG is available in Workbench from the Debug Shell view. The debug shell uses the same target connection defined from Workbench, so it is not necessary to use the WRDBG command target connect to connect a target.

WRDBG Current Context

By default, the current context of WRDBG matches the context selected in the Workbench Debug view. But as WRDBG requires that its current context must have a state (stopped, suspended, running …), only some contexts in the Debug view are valid from the shell perspective (for example, only tasks for VxWorks are valid). The Debug Shell view is activated only for those contexts. If the user selects other contexts, input to this view will be disabled.

As, by default, the Debug view drives the context selection of WRDBG, all WRDBG commands that are related to a context selection (thread, inferior …) or that may change the current context (thread create …) are disabled. The corresponding actions have to be performed from Workbench.

If the user wants to have full access to all WRDBG commands, (s)he has to release the link button of the Debug Shell view. In that case, the Debug view does not drive the context selection of the shell anymore. The shell current context is the last valid context selected by the user. If no valid context was selected before, the user will have to make the selection manually using the commands attach, thread, frame, task select, inferior …

If the user presses the link button again, the shell context will be defined again from the Debug view. The state of the link button is saved in the Workbench workspace and restored when Workbench starts.

At the top of the Debug Shell view, the status bar shows the current context of WRDBG.

Support of Multiple Targets

The Debug Shell view supports multiple target connections, but there is only one view and one tab for all connections. Each target connection has its own instance of WRDBG, and only the contents of the view change according to the target selection. It is not possible to reference another debug shell session from one debug shell session.

The user can switch from different connections only when the Debug view drives the shell’s current context (link button pressed). Otherwise, the last connection is used, or the first one if no connection has been used before.

At the top of the Debug Shell view, the status bar shows the connection currently used by WRDBG.

Line History

The current version of WRDBG accessed from the Debug Shell view does not expose commands to manipulate the line history. Moreover, this history is not preserved between sessions.

Debug Session Example

Here is a simple VxWorks RTP debug session using WRDBG from Workbench. We assume that the target is a vxsim target running on Linux, launched from Workbench.

From Workbench, create a VxWorks simulator connection, with the option “Start debugger after connect” selected. Connect the target. The Debug view should be visible; it displays all debuggable contexts (Kernel, tasks) currently running on the target.

If not already visible, open the Debug Shell view and make sure that the link button of the view (on the top right of the view) is selected.

In the Debug view, select one of the kernel tasks: the Debug Shell view is enabled. From Workbench, use the “Run/Debug Real Time Process…” action to debug a Philosophers RTP example (“Attach Debugger” option is selected), stopped at main (“Break at Main” option is selected).

The Debug view automatically selects the iPhilosophers initial task of the RTP, hence the current context of the Debug Shell view will also be this task (see the view’s status bar).

From the Debug Shell view, type:

(wrdbg) bt
#0  main (argc=3001, argv=0x10000) at phil.c:187
#1  0x0000000069000356      at _start+0x55

(wrdbg) list
182     (
183     int argc,
184     char * argv[]
185     )
186 #endif /* _WRS_KERNEL */
187     {
188 #ifndef _WRS_KERNEL
189     int                 options;        /* Demo's options */
190 #endif /* _WRS_KERNEL */
191     unsigned int        solution;       /* Either one of the impl. solutions */
(wrdbg)

It is possible to step the RTP initial task:

(wrdbg) n
main (argc=1, argv=0x6901c3c8) at phil.c:196
196     int     demoDuration = 0;           /* By default the demo runs forever */
(wrdbg) n
197     BOOL    philosophersNotReady = TRUE;/* FALSE when all philosopher tasks */

Set a breakpoint at line 404 of the current file (in the function philosopherRun) and continue the current task until the breakpoint is hit:

(wrdbg) break 404
Breakpoint 1 at 0x690007e0: file phil.c, line 404.
(wrdbg) continue
Continuing.

Breakpoint 1, philosopherRun (myNum=1, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
404     pPhilsAttr->iAmReady[myNum] = TRUE;

Breakpoint 1, philosopherRun (myNum=2, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
404     pPhilsAttr->iAmReady[myNum] = TRUE;

Breakpoint 1, philosopherRun (myNum=3, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
404     pPhilsAttr->iAmReady[myNum] = TRUE;

Breakpoint 1, philosopherRun (myNum=4, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
404     pPhilsAttr->iAmReady[myNum] = TRUE;

Breakpoint 1, philosopherRun (myNum=0, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
404     pPhilsAttr->iAmReady[myNum] = TRUE;

The breakpoint set from the debug shell is visible in the Breakpoints view. But it can only be disabled/enabled/deleted from the debug shell.

All the tPhil tasks of the RTP hit the breakpoint and a message is displayed for each of them, indicating where it is stopped.

The Debug view automatically selected the first task that hit the breakpoint, and it changes the current context of the shell too (both views are linked by means of the link button of the Debug Shell view):

(wrdbg) info thread
Kernel (P2.1619618824, procid: P2), 3 threads
 P2.1619618824, tNetConf
 P2.1621717024, ipcom_syslogd
 P2.1622996576, ipcom_tickd
philosophers.vxe (P1620254736.1620228880, procid: P1620254736), 6 threads
 P1620254736.1620228880, iPhilosophers
*P1620254736.1620353040, tPhil, philosopherRun (myNum=0, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
 P1620254736.1620353848, tPhil, philosopherRun (myNum=1, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
 P1620254736.1620354784, tPhil, philosopherRun (myNum=2, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
 P1620254736.1620356128, tPhil, philosopherRun (myNum=3, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
 P1620254736.1620357472, tPhil, philosopherRun (myNum=4, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404

(wrdbg) bt
#0  philosopherRun (myNum=0, solution=1, pPhilsAttr=0x69019ec4, pForksAttr=0x69019eb8, pStats=0x69019eb0) at phil.c:404
#1  0x00000000690051f6      at vxTaskEntry+0x76

(wrdbg) info args
myNum = 0
solution = 1
pPhilsAttr = 0x69019ec4
pForksAttr = 0x69019eb8
pStats = 0x69019eb0

It is possible to kill the current RTP from the debug shell:

(wrdbg) kill
Kill the program being debugged? (y or n) y
(wrdbg)

The RTP and all its tasks are removed from the Debug view and the RTPs node is selected; as this node is not a valid context from the debug shell perspective, the Debug Shell view is disable. You have to select another (valid) context in the Debug view to enable it back.

WRDBG Headless Mode

WRDBG can be accessed from the command line too by the application wrdbg. The user has to source the platform environment prior to using wrdbg:

cd <WIND_HOME>
./wrenv[.bat] -p <platform name>
wrdbg [options]

Warning

On Linux hosts, in order to have the line editing features and the history commands available, you must install the readline5 library (32-bit version on 64-bit hosts).

Command line options

-h, --help	Show this help message and exit.
-agentlog AGENTLOG	Agent connection event log file.
--cd DIR, -cd DIR	Change current directory to DIR.
--command FILE, -x FILE	Execute WRDBG commands from FILE.
--eval-command COMMAND, -ex COMMAND	Execute a single WRDBG command. May be used multiple times and in conjunction with --command.
--init-command FILE, -ix FILE	Like -x but execute commands before loading inferior.
--init-eval-command COMMAND, -iex COMMAND	Like -ex but before loading inferior.
-logfile LOGFILE	Log debug (very verbose) to LOGFILE.
--nh, -nh	Do not read ~/.wrdbg/rc.
--nx, -nx	Do not read any .wrdbginit files in any directory.
-quiet, -q	Do not redirect debuggee’s output in console.

Line History

The debug shell used from the command line has full support of all commands related to history, if the correct version of readline is installed on your host (in the case the host is a Linux OS - see warning note above). For a Windows host OS, the debug shell does not require a readline library.

(wrdbg) help set history
Generic command for setting command history parameters.

List of set history subcommands:

set history expansion -- Set history expansion on command input.
set history filename -- Set the filename in which to record the command history.
set history save -- Set saving of the history record on exit.
set history size -- Set the size of the command history.

Type "help set history" followed by history subcommand name for full documentation.
Command name abbreviations are allowed if unambiguous.

By default, the history is saved in the file $HOME/.wrdbg/history if the WRDBG variable history save is set to on (the default is on).

Target Connection

To connect to a target running a debug agent, the Wind River specific shell command target connect has been added to the set of available commands.

Synopsis

target connect URL [-logprefix PREFIX] [-logverbosity LEVEL] [-logdir LOGDIR]
                   [-kernel KERNEL|-config XML|-core COREFILE [-rtp RTP]]
                   [-timeout TIMEOUT] [-noos]

Connection parameters

Target URL

url

In the case of a network connection to the agent, the platform url is of the following form:

<platform>[:[<proxy>[/<proxy>[/...]]/]<target>]

where <proxy> and <target> are of the form [transport:]ip:port. Transport is TCP or UDP. You can have as many proxies as needed separated by /.

platform

The connected platform name. Possible values:

vxworks7

To connect to a target running a VxWorks 7 system. When using this platform, at least the -kernel and -logdir options must be used.

vxworks7-stopmode

VxWorks 7 stop mode. At least the -kernel and -logdir options must be provided. Only a UDP network connection to the VxWorks stop mode agent is supported. proxy is not supported.

vxworks7-asp

VxWorks 7 Advanced Simulation Platform. The -logdir option is mandatory.

vxworks7-coredump

VxWorks 7 core dump. The -logdir and -core options are mandatory. This URL does not need a target, and can be used like: target connect vxworks7-coredump -core <corefile> -logdir <dir>

vxworks653

The -config and -logdir options are mandatory.

windiss

To connect to a target running a WindISS system.

tcf

To connect to a target with a TCF agent running.

ip

The host name or IP address of the target to connect to.

port

The connection port of the TCF agent running on the connected target.

Coredump Path

-core corefile

The corefile defines the path to the corefile file used as a target. Path-mapping may be needed to have the correct behavior of the target once connected. This option may be used with the -rtp option to avoid setting path-mappings.

OS Awareness

-noos

Some connections like vxworks653 allow to disable the OS Awareness of the connected system. In that case, debug features are limited.

RTP Path

-rtp path

Together with the -core option, path points to the RTP which generated the attached corefile. The path must be the host path of the RTP, this allows WRDBG to create the needed path-mappings to retrieve debug bits.

Target Kernel

-kernel path

Path to the target kernel file. When connecting to a VxWorks target, this is mandatory, or the kernel symbols will not be available. The value of path must point to the file (on your host) which has been used to boot your VxWorks target.

Target Log Directory

-logdir dir

The path where the TCF logs are saved. Depending on the platform you want to connect to, a number of TCF value-add may be started by the target connect command. The standard output, standard error and (depending on the -logverbosity option) the TCF logs are saved in dir.

Target Log Prefix

-logprefix prefix

All the log files saved in the log directory are prefixed with prefix. Default prefix is wrdbg_.

Target Log Verbosity

-logverbosity level

The level representing the number of TCF logger to be inserted between the various TCF value-add and the TCF agent. For a VxWorks connection, the tcf-server value-add is started. The maximum verbosity is then 1, since a TCF logger may be inserted between the target agent and the tcf-server.

VxWorks653 XML Configuration File

-config xml

The xml defines the path to the VxWorks 653 XML config file. Additionnal -noos flag might be used for disabling the VxWorks653 OS awareness.

Define a new platform

The Wind River shell command target connect can be extended to support additional platforms.

File location

The file containing the source code of the new platform connection class must be located in one of the following folders:

• <HOME>/.wrdbg/extensions/commands (Linux host)
• <HOMEDRIVE><HOMEPATH>.wrdbg\extensions\commands (Windows host)
• <WIND_WRDBG_EXTENSION_PATH>. This environment variable must be defined by the user.

The platform connection class

The new target connection class must be a derived of WrDbgCommandExtension class.

The target plaform name is defined within the init method. This method is also used to define the platform specific parameters or options.

Some hooks are provided to extend target connect with a new platform:

• The parse method can be defined to parse a given line for a parameter. When the WrDbgCommand parser fails to parse an argument, it is sent to this method, hoping that the extension is able to handle the parameter.
• The precmd method is called after arguments parsing. For example, it can be used to make sure that all the mandatory parameters are defined. It can also be used to perform any action that needs to be done before connecting to the agent (for example, booting the target itself).
• The postcmd method is called after the connection has been established. For example, it can be used to display a connection completion message.

class skeleton:

class NewPlatformConnection(WrDbgCommandExtension):
 """My connection documentation header.

 My connection description.

 My connection specific options and parameters documentation.
 """

 def __init__(self):
     # Define new platform name
     WrDbgCommandExtension.__init__(self, <newPlatform>,
                                    'target connect')

     # Define plaform specific options or parameters here
     ...

 def parse(self, param, line):
     # Parse the given line for a parameter.
     ...

 def precmd(self, command, localvars):
     # Actions to perform called after arguments parsing
     ...

 def postcmd(self, command, localvars):
     # Actions to perform after parent command has finished
     ...

documentation

The platform connection documentation is accessible using Wind River shell command

(wrdbg) help target connect <newPlatform>

The list of supported platforms is listed by help target connect command.

examples

Here are few examples of already existing platform connections:

• $WIND_PYTHON_PATH/windriver/shells/wrdbg/commands/extensions/vxworks69.py
• $WIND_PYTHON_PATH/windriver/shells/wrdbg/commands/extensions/vxsim.py
• $WIND_PYTHON_PATH/windriver/shells/wrdbg/commands/extensions/vxworks7.py

Debug Session Example

Here is a simple VxWorks task debug session using WRDBG from the command line.

We assume that the target is a vxsim target running on Linux host.

cd <WIND_HOME>
./wrenv -p vxworks-7
vxsim -d simnet_nat -f <path to the VxWorks image>

As the simulator target launched uses a NAT networks, it is necessary to know the debug TCP port as seen on the host. From the vxsim output, it is necessary to localize the TCP port used for the debugger. This host TCP port is the one that matches the target TCP port 1534:

Checking License...OK
Virtual  Base Address: 0x10000000
Virtual  Top  Address: 0x48000000    Virtual  Size: 0x38000000 (896Mb)
Physical Base Address: 0x10000000
Physical Top  Address: 0x30000000    Physical Size: 0x20000000 (512Mb)
Loading...
0x38b250 + 0x3bc30
Redirecting TCP port 51331 to 10.0.10.2:21
Redirecting TCP port 51332 to 10.0.10.2:22
Redirecting TCP port 51333 to 10.0.10.2:23
Redirecting TCP port 51334 to 10.0.10.2:69
Redirecting TCP port 51335 to 10.0.10.2:80
Redirecting TCP port 51336 to 10.0.10.2:443
Redirecting TCP port 51337 to 10.0.10.2:1534 <= this line shows the debug port

 _________            _________
 \77777777\          /77777777/
  \77777777\        /77777777/
   \77777777\      /77777777/
    \77777777\    /77777777/
     \77777777\   \7777777/
      \77777777\   \77777/              VxWorks 7
       \77777777\   \777/
        \77777777\   \7/     Core Kernel version: 1.0.9.0

From another Linux shell (on the same host):

cd <WIND_HOME>
./wrenv -p vxworks-7
wrdbg

Now from the WRDBG command line, connect the debug agent of VxWorks using the correct port:

(wrdbg) target connect vxworks7:localhost:51337 -kernel <path to the VxWorks image> -logdir /tmp
Connecting...
Connected to TCP:127.0.0.1:51337

Attach to the Kernel context:

(wrdbg) ps
 P2  Kernel
     0x38002e10  tErfTask
     0x3811fc70  ipcom_syslogd
     0x380a58d8  tNetConf
     0x3842ea60  ipcom_tickd
(wrdbg) attach Kernel
[New Thread 2]
[New Thread 3]
[New Thread 4]
[New Thread 1]
[New inferior 2 (P2)]
Switching to inferior 2 [P2] (Kernel)
Attaching to process Kernel
(wrdbg)

Load the cobble kernel module, built from Workbench in /folk/user/workspace/cobble (this module is part of the VxWorks kernel module examples):

(wrdbg) module load /folk/user/workspace/cobble/vsb_linux_SIMLINUXgnu/cobble/Debug/cobble.out
Loading module /folk/user/workspace/cobble/vsb_linux_SIMLINUXgnu/cobble/Debug/cobble.out...done
(wrdbg) info modules
vxMod.0.6.P2 : /home/fredl/projects/windbase/target/proj/linux/32-bit/up/default/vxWorks
0x880d2278 : /folk/user/workspace/cobble/vsb_linux_SIMLINUXgnu/cobble/Debug/cobble.out

Create a kernel task to run the example, stopped at the entry point:

(wrdbg) thread create progStart
[New Thread 6]
Thread created: id = 6, name = t1
#0  progStart () at ../../src/kernel/cobble.c:111
111         {
(wrdbg) info threads
  Id     Type                  Name              Frame
  2      task of P2            ipcom_syslogd
  3      task of P2            tNetConf
  4      task of P2            ipcom_telnetd
  5      task of P2            ipcom_tickd
  1      task of P2            tErfTask
* 6      task of P2            t1                progStart () at ../../src/kernel/cobble.c:111

Set a breakpoint at the cosmos function and continue the current task:

(wrdbg) break cosmos
Breakpoint 1 at 0x606c0264: file ../../src/kernel/cobble.c, line 156.
(wrdbg) continue
Continuing.
[New Thread 7]
[New Thread 8]
[New Thread 9]
[New Thread 10]
Thread exited.

[Switching to Thread 2]
(wrdbg)
Breakpoint 1, cosmos () at ../../src/kernel/cobble.c:156
156         int nadaNichtsIdx = 0;

[Switching to Thread 7]

The current task has exited so the debug shell automatically switched to another task of the kernel (the current container).

The breakpoint has been hit by one of the tasks. When the debug shell is connected to a VxWorks agent, it is configured to behave identically to the GDB non-stop mode, that is all threads are manipulated individually by default by the runcontrol commands (like continue, step …). Moreover, when a breakpoint is hit, the debug shell automatically switches to that task. This behavior is handled by the auto-switch variable.

(wrdbg) show auto-switch
Automatically switching to suspended thread mode is on.
(wrdbg) info threads
  Id     Type                  Name              Frame
  2      task of P2            ipcom_syslogd
  3      task of P2            tNetConf
  4      task of P2            ipcom_telnetd
  5      task of P2            ipcom_tickd
  1      task of P2            tErfTask
* 7      task of P2            tCosmos           cosmos () at ../../src/kernel/cobble.c:156
  8      task of P2            tSchlep
  9      task of P2            tCrunch
  10     task of P2            tMonitor
(wrdbg) backtrace
#0  cosmos () at ../../src/kernel/cobble.c:156
#1  0x00000000600c1cd1 at vxTaskEntry+0x11
(wrdbg)  l
151     * datum is available and may be read from the cosmicData variable.
152     */
153
154     void cosmos (void)
155         {
156         int nadaNichtsIdx = 0;
157
158         FOREVER
159             {
160             if (nadaNichtsIdx != LUCKY)

Step the current task:

(wrdbg) n
159         if (nadaNichtsIdx != LUCKY)
(wrdbg) [ENTER]
160             cosmicData = rand ();
(wrdbg) [ENTER]
167         ++nadaNichtsIdx;
(wrdbg) info locals
nadaNichtsIdx = 0
(wrdbg) n
170         semGive (dataSemId);
(wrdbg) info locals
nadaNichtsIdx = 1
(wrdbg)