vxworks_kernel_shell_users_guide_6.9

VxWorks Kernel Shell®USER'S GUIDE

6.9

Edition 3

Copyright © 2011 Wind River Systems, Inc.

All rights reserved. No part of this publication may be reproduced or transmitted in any

form or by any means without the prior written permission of Wind River Systems, Inc.

Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc.

The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party

trademarks referenced are the property of their respective owners. For further information

regarding Wind River trademarks, please see:

http://www.77cn.com.cn/company/terms/trademark.html

This product may include software licensed to Wind River by third parties. Relevant

notices (if any) are provided in your product installation at the following location:

installDir/product_name/3rd_party_licensor_notice.pdf.

Wind River may refer to third-party documentation by listing publications or providing

links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.

Corporate Headquarters

Wind River

500 Wind River Way

Alameda, CA 94501-1153

U.S.A.

Toll free (U.S.A.):800-545-WIND

Telephone: 510-748-4100Facsimile: 510-749-2010

For additional contact information, see the Wind River Web site:

http://www.77cn.com.cn

For information on how to contact Customer Support, see:

http://www.77cn.com.cn/support

VxWorks Kernel Shell

User's Guide

6.9

Edition 326 Oct 11

Contents

1Overview ......................................................................................................

1.1Introduction ......................................................................................................................

1.2Related Documentation Resources ..............................................................................

1.3VxWorks Configuration and Build ..............................................................................2Kernel Shell .................................................................................................

2.1Introduction ......................................................................................................................

2.2About the Kernel Shell ..................................................................................................

2.3About the C Interpreter and Command Interpreter .................................................

2.4About Wind River CLI Shell Access ...........................................................................

2.5About Kernel and HostShell Differences .................................................................

2.6Configuring VxWorks With the Kernel Shell ...........................................................

2.6.1Required Kernel Shell Components ...............................................................

2.6.2Optional Kernel Shell Components ................................................................

2.7Setting Configuration Variables for Kernel Shell Sessions ...................................

2.7.1Kernel Shell Configuration Variables ............................................................

2.7.2Configuring Kernel Shell Configuration Variables Statically .....................

2.7.3Configuring Kernel Shell Configuration Parameters Dynamically ...........

2.8Starting the Kernel Shell ...............................................................................................

2.9Using Kernel Shell Help ................................................................................................

2.10Using Kernel Shell Control Characters .......................................................................

2.11Calling C Routines From the C Interpreter ................................................................

Calling VxWorks Image Routines by Name .................................................11223445668810121213131414151616

iii

VxWorks Kernel ShellUser's Guide, 6.9 Calling Downloadable Kernel Module Routines by Name ........................

Argument Limit .................................................................................................

2.12Aborting Routines Executing from the Kernel Shell ...............................................

2.13Switching Between Interpreters ..................................................................................

2.14Switching Between Kernel and RTP Memory Contexts .........................................

2.15Executing Commands With the Inactive Interpreter ................................................

2.16Kernel Shell History .......................................................................................................

2.17Defining Kernel Shell Command Aliases ..................................................................

2.18Debugging With the Kernel Shell ..............................................................................

2.18.1Using Dynamic Printf ......................................................................................

Configuring VxWorks for Dynamic Printf ....................................................

Dynamic Printf Example ..................................................................................

2.18.2Debugging Kernel Tasks .................................................................................

2.18.3Debugging RTP Applications .........................................................................

Adding Dynamic Printfs to RTP Applications .............................................

Starting Tasks and Calling Routines in a Real-Time Process .....................

Monitoring System Calls .................................................................................

2.18.4Debugging SMP Systems With the Kernel Shell .........................................

2.19Kernel Shell Security .....................................................................................................

2.20Using a Remote Login to the Kernel Shell .................................................................

2.21Launching a Shell Script Programmatically ..............................................................

2.22Executing Shell Commands Programmatically .........................................................

2.23Accessing Kernel Shell Data Programmatically .......................................................

2.24Adding Custom Commands to the Command Interpreter .....................................

2.24.1Creating A New Command .............................................................................

Defining a Command .......................................................................................

Writing the Command Routine ......................................................................

Registering a New Command .........................................................................

2.24.2Sample Custom Commands ............................................................................

2.25Creating a Custom Interpreter ......................................................................................

2.25.1Sample Custom Interpreter .............................................................................

3Kernel Object-Module Loader ....................................................................

3.1Introduction ......................................................................................................................iv161617181819191919202020212222222425262627273030313132333434363939

3.2About the Kernel Object-Module Loader ..................................................................

3.2.1Relocatable ELF Object Files ............................................................................

3.2.2Processing the Contents of an ELF Object File ..............................................

3.2.3Linking and Reference Resolution ..................................................................

3.3Kernel and Host Loader Differences ...........................................................................

3.3.1Relationship to VxWorks Target .....................................................................

3.3.2Module and Symbols Synchronization ..........................................................

3.3.3Memory management ......................................................................................

3.3.4System Debug Mode .........................................................................................

3.4Configuring VxWorks with the Kernel Object-Module Loader ............................

3.4.1Compiler Intrinsics Support for C Modules .................................................

3.5Kernel Object-Module Loader APIs and Shell Commands ...................................

3.6Summary List of Kernel Object-Module Loader Options ......................................

3.7Loading C Modules Into the Kernel ............................................................................

3.8Loading C++ Modules into the Kernel .......................................................................

3.8.1Use a Single C++ Module ................................................................................

3.8.2Munching a C++ Application Module ...........................................................

3.8.3Calling Static Constructors and Destructors Interactively ..........................

3.9Memory Location Options for Module Loading .......................................................

3.9.1Default Memory Location for 32-Bit VxWorks .............................................

3.9.2Default Memory Location Options for 64-bit VxWorks ..............................

Using the 64-Bit Kernel Proximity Heap .......................................................

Using the 64-Bit Kernel Common Heap ........................................................

3.9.3Specific Memory Locations for 32-Bit and 64-Bit VxWorks ........................

3.10Caveats for Kernel Object-Module Loader Use ........................................................

3.10.1Module Types Must Match VxWorks System ..............................................

3.10.2Load Sequence Requirements .........................................................................

3.10.3Resolving Common Symbols ..........................................................................

3.10.4Resolving Weak Symbols .................................................................................

3.10.5Stripping Symbols From Modules ..................................................................

3.10.6Function Calls, Relative Branches, and Load Failures .................................

3.10.7Kernel Object Modules With SDA ..................................................................

3.10.8Unresolved Symbols and Compiler Intrinsics .............................................. Contents394041414242434343444545465050515153535354545555565657575859595960

v

VxWorks Kernel ShellUser's Guide, 6.9 4Kernel Symbol Table ..................................................................................

4.1

4.2Introduction ......................................................................................................................About Kernel Symbol Tables .......................................................................................616161

4.2.1System Symbol Table ........................................................................................

4.2.2Symbol Entries ...................................................................................................

4.2.3Symbol Updates ................................................................................................

4.2.4Searching the Symbol Library .........................................................................

4.3Configuring VxWorks with Symbol Tables ..............................................................

4.3.1Configuration for User Symbol Tables ..........................................................

4.3.2Configuration for a System Symbol Table .....................................................

4.4Creating a Built-In System Symbol Table ..................................................................

4.4.1Generating the Symbol Information ...............................................................

4.4.2Compiling and Linking the Symbol File ........................................................

4.5Creating a Loadable System Symbol Table ...............................................................

4.5.1Creating the .sym File .......................................................................................

4.5.2Loading the .sym File .......................................................................................

4.6Synchronizing Host and Kernel Modules List and Symbol Table .......................

4.7Creating and Using User-Defined Symbol Tables ...................................................

5Show Routines ............................................................................................

5.1Introduction ......................................................................................................................

5.2About VxWorks Show Routines ..................................................................................

6Common Problems .....................................................................................

6.1Introduction ......................................................................................................................

6.2Kernel Shell Debugging Never Hits a Breakpoint ...................................................

6.3Insufficient Memory .......................................................................................................

6.4Download "Relocation Does Not Fit" Error Message ..............................................

6.5Missing Symbols .............................................................................................................

6.6Kernel Object-Module Loader is Using Too Much Memory .................................

6.7Symbol Table Unavailable ............................................................................................

6.8Kernel Shell Debugging is Slow ..................................................................................vi626363636464646565656666666667696969717171727373747475

1

Overview

1.1Introduction1

1.2Related Documentation Resources2

1.3VxWorks Configuration and Build2

1.1 Introduction

The Wind River host development environment provides tools that reside and

execute on the host machine. This approach conserves target memory and

resources. However, there are many situations in which it is desirable to make use

of target-resident facilities: a target-resident shell, kernel object-module loader,

debugging facilities, and system symbol table. The uses for these target-resident

tools include the following:

■Debugging a deployed system over a serial connection.

Developing and debugging network protocols, where it is useful to see the

target's view of a network.

Loading kernel modules from a target disk, from ROMFS, or over the network,

and running them interactively (or programmatically). ■■

The target based tools are partially independent of each other. For example, the

kernel shell may be used without the kernel object-module loader, and vice versa.

However, for any of the other individual tools to be completely functional, the

system symbol table is required.

In some situations, it may be useful to use both the host-resident development

tools and the target-resident tools at the same time. In this case, additional facilities

are required so that both environments maintain consistent views of the system.

(For more information, see 4.6Synchronizing Host and Kernel Modules List and

Symbol Table, p.66.)

This guide describes the features and use of the VxWorks target-resident kernel

shell, object-module loader, debugging facilities, and system symbol table. It also

provides an overview of the most commonly used VxWorks show routines, which are executed from the shell.

1

VxWorks Kernel ShellUser's Guide, 6.9

1.2 Related Documentation Resources

Detailed information about VxWorks libraries and routines is provided in the

VxWorks API references. Information specific to target architectures is provided in

the VxWorks BSP references and in the VxWorks Architecture Supplement. For

information about the host shell, see the WindRiver Workbench Host Shell User’s

Guide.

1.3 VxWorks Configuration and Build

This document describes VxWorks features and their use; it does not go into detail

about the mechanisms by which VxWorks systems are configured and built. The

tools and procedures used for configuration and build are described in the Wind

River Workbench by Example guide and the Wind River Platforms User’s Guide.

NOTE: In this guide, as well as in the VxWorks API references, VxWorks

components and their configuration parameters are identified by the names used

in component description files. The names take the form, for example, of

INCLUDE_FOO and NUM_FOO_FILES (for components and parameters,

respectively).

You can use these names directly to configure VxWorks using the command-line

configuration facilities.

Wind River Workbench displays descriptions of components and parameters, as

well as their names, in the Components tab of the Kernel Configuration Editor.

You can use the Find dialog to locate a component or parameter using its name or

description. To access the Find dialog from the Components tab, type CTRL+F, or

right-click and select Find.

2

2

Kernel Shell

2.1Introduction4

2.2About the Kernel Shell4

2.3About the C Interpreter and Command Interpreter5

2.4About Wind River CLI Shell Access6

2.5About Kernel and HostShell Differences6

2.6Configuring VxWorks With the Kernel Shell8

2.7Setting Configuration Variables for Kernel Shell Sessions12

2.8Starting the Kernel Shell14

2.9Using Kernel Shell Help14

2.10Using Kernel Shell Control Characters15

2.11Calling C Routines From the C Interpreter16

2.12Aborting Routines Executing from the Kernel Shell17

2.13Switching Between Interpreters18

2.14Switching Between Kernel and RTP Memory Contexts18

2.15Executing Commands With the Inactive Interpreter19

2.16Kernel Shell History19

2.17Defining Kernel Shell Command Aliases19

2.18Debugging With the Kernel Shell19

2.19Kernel Shell Security26

2.20Using a Remote Login to the Kernel Shell26

2.21Launching a Shell Script Programmatically27

2.22Executing Shell Commands Programmatically27

2.23Accessing Kernel Shell Data Programmatically30

2.24Adding Custom Commands to the Command Interpreter30

2.25Creating a Custom Interpreter34

3

VxWorks Kernel ShellUser's Guide, 6.9

2.1 Introduction

The VxWorks kernel shell is a target-resident shell that can be accessed locally

from a host system over a serial connection using a terminal utility (such as tip or

HyperTerminal), remotely over a network connection (using telnet, rlogin), or

using the wtxConsole.1

2.2 About the Kernel Shell

The VxWorks kernel shell provides a shell interface that can be used to execute,

monitor, and debug kernel and RTP code, as well as to monitor and debug general

system performance. For most uses, the kernel shell requires the system symbol

table. It can also be used with the kernel object module loader to download object

code into kernel space (for information in this regard, see 3.Kernel Object-Module

Loader).

The kernel shell has two interpreters—the C interpreter and the command

interpreter—each of which has its own set of commands. The C interpreter can also

be used to execute any VxWorks kernel routines, or any routines that have been

added to kernel space with downloadable kernel modules. The command

interpreter, on the other hand, is similar to a UNIX shell. In contrast with the C

interpreter (for which all commands are C system functions), the command

interpreter commands are statically registered. This means that the command

interpreter can be used without the system symbol table.

For the most part, the target-resident kernel shell works the same as the host shell,

except that it executes entirely in the target system. In addition, the kernel shell

only provides the C interpreter and command interpreter (others may be

registered by the user), whereas the host shell provides additional facilities (see

2.5About Kernel and HostShell Differences, p.6 for information about other

differences).

For detailed information about the host shell and the shell interpreters, see the

WindRiver Workbench Host Shell User’s Guide, and the online Wind River Host Shell

API Reference.

Multiple kernel shell sessions may be run simultaneously, which allows for

simultaneous access to the target from the host console and remote connections

made with telnet or rlogin.

NOTE: VxWorks is a single-user operating system. It does not support

simultaneous use by more than one user. While multiple kernel shell sessions may

be run concurrently, they must all be started by the same user. The kernel shell can,

however, be configured so that each shell session has its own current working

directory variable.

1.In versions of VxWorks prior to 6.0, the kernel shell was called the target shell. The new

name reflects the fact that the target-resident shell runs in the kernel and not in a process.

4

2 Kernel Shell

2.3 About the C Interpreter and Command Interpreter

NOTE: The kernel shell operates only with int, long, short, char, double, or float

data types.

CAUTION: Do not use hardware breakpoints with the kernel shell and an On-Chip

Debugging (OCD) tool at the same time. Simultaneous use may lead to

unpredictable debugging behavior, as both facilities access hardware breakpoint

registers.

2.3 About the C Interpreter and Command Interpreter

The kernel shell includes both a C interpreter and a command interpreter. Their

basic differences are as follows:

■The command interpreter is designed primarily for starting, monitoring, and

debugging real-time process (RTP) applications. It can also be used in

conjunction with the kernel object module loader to load and unload kernel

object modules. It provides a UNIX-like shell environment.

The C interpreter is designed primarily for monitoring and debugging

kernel-based code. It can be used for loading, running, and unloading object

modules in conjunction with the kernel object-module loader. In addition, it

provides some APIs for starting and monitoring RTP applications. The C

interpreter operates on C routines, whether provided by VxWorks libraries or

user’s kernel code that is either linked with VxWorks or downloaded into the

target system.

CAUTION: When a routine is called from the kernel shell, the routine is ■executed in the context of the shell task. If execution of the routine hangs, the

shell session will hang as well.

For detailed information about the interpreters, see the WindRiver Workbench Host

Shell User’s Guide. For information about the commands supported by each

interpreter, see Interpreter Commands and References, p.5.

For information about adding new commands to the command interpreter, and

creating interpreters for the kernel shell, see 2.24Adding Custom Commands to the

Command Interpreter, p.30 and 2.25Creating a Custom Interpreter, p.34.

For information about help available from the kernel shell itself, see 2.9Using

Kernel Shell Help, p.14.

Interpreter Commands and References

For information about individual C interpreter routines, see the usrLib, dbgLib,

and usrShellHistLib sections in the VxWorks Kernel API Reference, as well as

entries for the various show routine libraries. The dbgLib routines are particularly

useful, providing commands for managing task breakpoints, task single-stepping,

symbolic disassembly, and symbolic task stack tracing.

Note that the kernel shell can also call any C routine that returns a data type

supported by the shell (int, long, short, char, double, or float). For example,

5

VxWorks Kernel ShellUser's Guide, 6.9 semaphores can be created and manipulated from the shell using the VxWorks

semaphore APIs.

2.4 About Wind River CLI Shell Access

The Wind River CLI shell can be accessed from the kernel shell, provided that

VxWorks has been appropriately configured with Wind River CLI support. For

information in this regard, see the Wind River CLI, Web, MIBway Programmer's

Guide.

2.5 About Kernel and HostShell Differences

The major differences between the target and host shells are the following:

■The host and kernel shells do not provide exactly the same set of commands.

The kernel shell, for example, has commands related to network, shared data,

environment variables, and some other facilities that are not provided by the

host shell. However, the host and kernel shells provide a very similar set of

commands for their command and C interpreters.

Each shell has its own distinct configuration parameters, as well as those that

are common to both.

Both shells include a command and a C interpreter. The host shell also

provides a Tcl interpreter and a gdb interpreter. The gdb interpreter has about

40 commands and is intended for debugging processes (RTPs); and it

references host file system paths.

For the host shell to work, VxWorks must be configured with the WDB target

agent component (see the VxWorks Kernel Programmer’s Guide: WDB Target

Agent). For the kernel shell to work, VxWorks be configured with the kernel

shell component, as well as the target-resident symbol tables component.

The host shell can perform many control and information functions entirely on

the host, without consuming target resources.

The kernel shell does not require any Wind River host tool support.

The host shell uses host system resources for most functions, so that it remains

segregated from the target. This means that the host shell can operate on the

target from the outside, whereas the kernel shell is part of the VxWorks kernel.

For example, the host shell version of the w() command does not allocate

memory on the target, whereas the kernel shell version of w() does allocate

memory on the target. Conflicts in task priority may also occur while using the kernel shell.■■■■■■

6

2 Kernel Shell

2.5 About Kernel and HostShell Differences

!WARNING: Shell commands must be used in conformance with the routine

prototype, or they may cause the system to hang.

■The kernel shell has its own set of terminal-control characters, unlike the host

shell, which inherits its setting from the host window from which it was

invoked. (See 2.10Using Kernel Shell Control Characters, p.15.)

The kernel shell correctly interprets the tilde operator in path names for UNIX

and Linux host systems (or remote file systems on a UNIX or Linux host

accessed with ftp, rsh, NFS, and so on), whereas the host shell cannot. For

example, the following command executed from the kernel shell (with the C

interpreter) by user panloki would correctly locate the kernel module

/home/panloki/foo.o on the host system and load it into the kernel:

->ld<~/foo.o ■

■When the kernel shell encounters a string literal (“...”) in an expression, it

allocates space for the string, including the null-byte string terminator, plus

some additional overhead.1 The value of the literal is the address of the string

in the newly allocated storage. For example, the following expression allocates

12-plus bytes from the target memory pool, enters the string in that memory

(including the null terminator), and assigns the address of the string to x:

->x="hellothere"

The following expression can be used to return the memory to the target

memory pool (see the memLib reference entry for information on memory

management):

->free(x)

Furthermore, even when a string literal is not assigned to a symbol, memory

is still permanently allocated for it. For example, the following expression uses

memory that is never freed:

-> printf("hellothere")

This is because if strings were only temporarily allocated, and a string literal

was passed to a routine being spawned as a task, by the time the task executed

and attempted to access the string, the kernel shell would have already

released (and possibly even reused) the temporary storage where the string

was held.

If the accumulation of memory used for strings has an adverse effect on

performance after extended development sessions with the kernel shell, you

can use the strFree() routine (with the C interpreter) or the equivalent

stringfree command (with the command interpreter).

The host shell also allocates memory on the target if the string is to be used

there. However, it does not allocate memory on the target for commands that

can be performed at the host level (such as lkup(), ld(), and so on).

1.The amount of memory allocated is rounded up to the minimum allocation unit for the

architecture in question, plus the amount for the header for that block of memory.

7

VxWorks Kernel ShellUser's Guide, 6.9

2.6 Configuring VxWorks With the Kernel Shell

The functionality of the kernel shell is provided by a suite of components, some of

which are required, and others of which are optional.

2.6.1 Required Kernel Shell Components

Table 2-1

8To use the kernel shell, you must configure VxWorks with the INCLUDE_SHELL component. The configuration parameters for this component are described in Table2-1. You must also configure VxWorks with components for symbol table support—unless you are only going to use the command interpreter—using either the INCLUDE_STANDALONE_SYM_TBL or INCLUDE_NET_SYM_TBL component. For information about configuring VxWorks with symbol tables, see 4.3Configuring VxWorks with Symbol Tables, p.64.INCLUDE_SHELL Configuration Parameters Configuration ParameterDescriptionSHELL_SECUREAccess the kernel shell attached to the console through a login process. See 2.19Kernel Shell Security, p.26. SHELL_STACK_SIZEDefault stack size for each instance of a kernel shell task. SHELL_TASK_NAME_BASEThe basename for each instance of a kernel shell task. The default is tShell. An integer is added to the basename to identify each instance of a kernel shell task, starting with zero and incremented for each additional instance. Note that remote shell sessions (such as those initiated by rlogin or telnet) have a task basename of tShellRem. SHELL_TASK_PRIORITYPriority for each instance of a kernel shell task.SHELL_SPAWNED_TASK_STACK_SIZEThe stack size of a task spawned from the shell with sp(), period(), or repeat(). It can subsequently be modified at runtime using the spTaskStackSize global variable; see the usrLib API reference. SHELL_SPAWNED_TASK_PRIORITY The priority of a task spawned from the shell with sp(), period(), or repeat(). It can subsequently be modified at runtime using the spTaskPriority global variable; see the usrLib API reference.

2 Kernel Shell

2.6 Configuring VxWorks With the Kernel Shell

Table 2-1INCLUDE_SHELL Configuration Parameters (cont’d)

Configuration ParameterDescription

SHELL_SPAWNED_TASK_OPTIONS The task options of a task spawned

from the shell with sp(), period(), or

repeat(). It can subsequently be

modified at runtime using the

spTaskOptions global variable; see the

usrLib API reference.

Task creation options for the kernel

shell tasks. For more information about

task creation options, see the VxWorks

Kernel Programmer’s Guide: Multitasking.

The kernel shell is launched

automatically at boot time on the

console.

The kernel shell is configured to be

compatible with the VxWorks 5.5 shell,

with a limit of one shell session, global

I/O redirection, and shell task options

without the VX_PRIVATE_ENV bit. This

option cannot be used with

SHELL_SECURE set to TRUE, with

SHELL_START_AT_BOOT set to FALSE,

or with SHELL_MAX_SESSIONS set to

anything other than -1.

The default configuration variables for

kernel shell sessions. They can

subsequently be modified at runtime.

See 2.7Setting Configuration Variables for

Kernel Shell Sessions, p.12.

The default configuration variables for

the initial kernel shell session can be set

independently of other sessions using

this parameter. They can subsequently

be modified at runtime. See 2.7Setting

Configuration Variables for Kernel Shell

Sessions, p.12. SHELL_TASK_OPTIONSSHELL_START_AT_BOOTSHELL_COMPATIBLESHELL_DEFAULT_CONFIGSHELL_FIRST_CONFIG

9

VxWorks Kernel ShellUser's Guide, 6.9

Table 2-1INCLUDE_SHELL Configuration Parameters (cont’d)

Configuration ParameterDescription

SHELL_REMOTE_CONFIGThe configuration variables for kernel

shell sessions started for a remote

connection can be set independently of

local sessions using this parameter.

They can subsequently be modified at

runtime. See 2.7Setting Configuration

Variables for Kernel Shell Sessions, p.12.

The maximum number of shell

sessions. The default is unlimited

(defined with -1). When a session limit

is set and reached, further connections

are rejected (with a message to the

console). The limitation is enforced

whether or not the sessions are secured

(that is, authenticated) and whether or

not they are local (console shell or

remote shell). The limitation is

independent of any that might be

implemented by a telnet, rlogin, or SSH

server. SHELL_MAX_SESSIONS

2.6.2 Optional Kernel Shell Components

Table2-2 describes components that provide additional shell functionality.

Table 2-2Optional Shell Components

ComponentDescription

INCLUDE_DEBUGDebugging facilities, such as disassembly,

task stack trace, setting a breakpoint,

stepping, and so on.

Display the shell banner on startup.

Editing mode similar to the vi editing mode.

Editing mode similar to the Emacs editing

mode.

C interpreter. See 2.3About the C Interpreter

and Command Interpreter, p.5.

Command interpreter. See 2.3About the C

Interpreter and Command Interpreter, p.5.

Kernel shell startup script facility.

Shell history commands. INCLUDE_SHELL_BANNERINCLUDE_SHELL_VI_MODEINCLUDE_SHELL_EMACS_MODEINCLUDE_SHELL_INTERP_CINCLUDE_SHELL_INTERP_CMDINCLUDE_STARTUP_SCRIPTINCLUDE_SHELL_HISTORY_FILE

10

2 Kernel Shell

2.6 Configuring VxWorks With the Kernel Shell

Table2-3 describes components that provide additional command interpreter

functionality. They must be used with the INCLUDE_SHELL_INTERP_CMD

component (described above in Table2-2).

Table 2-3Command Interpreter Components

ComponentDescription

INCLUDE_DISK_UTIL_SHELL_CMD

INCLUDE_EDR_SHELL_CMD

INCLUDE_TASK_SHELL_CMD

INCLUDE_DEBUG_SHELL_CMD

INCLUDE_SYM_SHELL_CMD

INCLUDE_VM_SHOW_SHELL_CMD

INCLUDE_ADR_SPACE_SHELL_CMDFile system shell commands.Error detection and reporting shell commands.Task shell commands.Debug shell commands.Symbol shell commands.Virtual memory show shell commands.Address space shell

commands.

commands.INCLUDE_SHARED_DATA_SHOW_SHELL_CMDShared data show shell

INCLUDE_MEM_EDR_SHELL_CMD

INCLUDE_MEM_EDR_RTP_SHELL_CMDMemory detection and reporting shell commandsMemory detection and

reporting shell commands for

processes (RTPs).

Kernel loader shell command.

Kernel unloader shell

command.

Shared library commands for

processes.

Process shell commands.

Process show shell

commands.

Shell history commands. INCLUDE_MODULE_SHELL_CMDINCLUDE_UNLOADER_SHELL_CMDINCLUDE_SHL_SHELL_CMDINCLUDE_RTP_SHELL_CMDINCLUDE_RTP_SHOW_SHELL_CMDINCLUDE_HISTORY_FILE_SHELL_CMD

Additional components that are useful are the following:

INCLUDE_DISK_UTIL

Provides file utilities, such as ls and cd (it is required by

INCLUDE_DISK_UTIL_SHELL_CMD).

INCLUDE_SYM_TBL_SHOW

Provides symbol table show routines, such as lkup.

It can also be useful to include components for the kernel object-module loader

and unloader (see 3.4Configuring VxWorks with the Kernel Object-Module Loader,

11

VxWorks Kernel ShellUser's Guide, 6.9 p.44). These components are required for the usrLib commands that load modules

into, and unload modules from, the kernel (see 3.7Loading C Modules Into the

Kernel, p.50 and 3.8Loading C++ Modules into the Kernel, p.50).

Note that the BUNDLE_STANDALONE_SHELL and BUNDLE_NET_SHELL

component bundles are also available to provide for a standalone kernel shell or a

networked kernel shell.

2.7 Setting Configuration Variables for Kernel Shell Sessions

Kernel shell configuration variables are used to control various settings for shell

sessions, including identifying the current shell interpreter (command or C), line

edit mode (vi or Emacs), and so on. It can be useful to think of these variables as

session variables. Note that the shell’s configuration variables are not VxWorks

environment variables (which are themselves unlike UNIX environment variables;

for more information about environment variables, see the envLib entry in the

VxWorks API references).

The defaults for configuration variables are set initially as part of configuring

VxWorks and the kernel shell at build time (statically). They can subsequently be

modified at runtime (dynamically).

2.7.1 Kernel Shell Configuration Variables

The kernel shell provides several configuration variables itself, and other facilities

provide additional variables. Some of the shell’s configuration variables are the

following:

INTERPRETER

Identify the interpreter, either C or Cmd. The default is the first interpreter

registered (the C interpreter).

LINE_EDIT_MODE

Set the line edit mode, either Emacs or vi. The default is the first line edit mode

style registered (vi mode).

LINE_LENGTH

Set the shell line length (it cannot be changed dynamically). The default is 256

characters.

The set of configuration variables that are available depends on the configuration

of the VxWorks system itself. For example, RTP_CREATE_STOP is only available if

VxWorks is configured with process support and the command interpreter

component (INCLUDE_RTP and INCLUDE_SHELL_INTERP_CMD).

The kernel shell’s variables are listed in the shellLib API reference. Others are

listed in the API references associated with their functionality (for example,

taskspawn, which provides RTP_TASK_SPAWN_PRIO,

RTP_TASK_SPAWN_STACK_SIZE and RTP_TASK_SPAWN_OPTS).

12

2 Kernel Shell

2.7 Setting Configuration Variables for Kernel Shell Sessions2.7.2 Configuring Kernel Shell Configuration Variables Statically

The default values for kernel shell configuration variables are set statically—when

VxWorks is configured using Workbench or the vxprj tool—with the following

component parameters:

SHELL_DEFAULT_CONFIG

The default settings of configuration variables for all shell sessions, except for

any configuration variables overridden (on a variable by variable basis) by

SHELL_FIRST_CONFIG or SHELL_REMOTE_CONFIG for the first or remote

sessions, respectively.

SHELL_FIRST_CONFIG

Configuration variables for the initial shell session launched at boot time.

Overrides SHELL_DEFAULT_CONFIG for any configuration variables set. By

default it is set to NULL.

SHELL_REMOTE_CONFIG

Configuration variables for remote sessions (telnet or rlogin). Overrides

SHELL_DEFAULT_CONFIG for any configuration variables set. By default it is

set to NULL.

Each of these parameters can be set to a string of configuration variables or used to

change individual values.

For example, to set the path to RTP application executables with the VXE_PATH

configuration parameter from the command-line you would use the following

command:

vxprj parameter setstring SHELL_DEFAULT_CONFIG "VXE_PATH=/home/xeno:/romfs"

This example illustrates setting multiple configuration parameters at once:

vxprj parameter setstring SHELL_DEFAULT_CONFIG

"LINE_EDIT_MODE=emacs,LINE_LENGTH=256,STRING_FREE=manual,INTERPRETER=Cmd,VXE_PAT

H=.;/romfs"

Note that commas are used to separate arguments.

2.7.3 Configuring Kernel Shell Configuration Parameters Dynamically

Kernel shell configuration variables can be changed dynamically at runtime (either

interactively or programmatically) for a shell given session.

Configuration variables can be changed using shConfig() with the C interpreter,

or using the setconfig command with the command interpreter. They can also be

changed programmatically using shellConfigDefaultSet() to set defaults for all

sessions, and shellConfigSet() to set variables for a particular session.

For example, the following shell command changes line-edit mode to Emacs:

[vxWorks]# set config LINE_EDIT_MODE="emacs"

13

本文来源：https://www.bwwdw.com/article/m30j.html