White Paper: Red Hat Crash Utility |
||
![]() |
||
< Prev | Contents | Next > |
![]() |
Command ExtensionsFrequently users wish to add an additional option to an existing crash command, or add a brand new command, in order to address a kernel issue they are debugging or developing. For those reasons, the crash utility was designed with extensibility in mind. There are two ways to add new functionality:
This section consists of a quick guide that describes how to get started using both methods. Adding new code and compiling it into the crash executableThe current set of crash commands can be seen by entering the help command with no arguments:
For each command in the menu above, there is an entry in a data structure in the file global_data.c, which is located in the top-level directory of the crash source code tree:
Each entry consists of the following simple data structure:
The structure members consist of:
For a newly-written command to appear in the help menu, it simply requires a reference to it in the structure above. To test a new command without adding it to the menu, use the hidden "test" command, found in test.c:
The test command contains the basic template used by crash commands to accept dash-arguments, which are fielded by the getopt() routine, while all other command line arguments are fielded in the while loop. To add an option to the test command (or any other existing command), simply fit it into the appropriate argument-gathering mechanism. Or, for that matter, if no arguments are required, put the functionality at the end of the command's function. Here is a trivial example of a change to the cmd_test() function, with the modifications highlighted:
Then re-compile crash by entering make:
Then run the test command with the tree possible argument types:
The easiest way to implement a new command's functionality is to use an existing command as a template. There is a broad range of utility routines that handle argument strings, read memory, access data structures and their members, display data, and so on, that obviate the need to reinvent the wheel to accomplish a task. Look at what other similar commands do, and copy their mechanisms. Creating a shared object library and loading it with extendWhile adding a new command and/or command option in the manner above is useful, it would require the same integration mechanism with each subsequent release of the crash utility. Since that could become tedious, another extension mechanism exists in which share objects containing one or more crash commands can be written, and then dynamically attached to a running crash session, using the extend command. Once loaded, the command(s) in the shared object library automatically appear in the help menu, as if they were compiled into the crash executable. As an quick aid in creating a shared object, the help page for the extend contains an example C program tagged onto the end, which adds a new echo command (which simply echoes back all arguments). The C program piece can be cut and pasted into a file, say extlib.c for example, and then compiled like so:
The resultant extlib.so file may be dynamically linked into crash during runtime using the extend command:
Or, to automatically load the shared library during crash session initialization, put the following string into a .crashrc file located in the current directory, or in the user's $HOME directory:
Here is the help menu once the library is loaded; note the integration of the new echo command:
With this extension mechanism, the most that would be required to use the shared library with subsequent versions of crash would be a simple re-compile of the extlib.c file. |
![]() |
||
< Prev | Contents | Next > |
![]() |