ChorusOS 5.0 Debugging Guide

Chapter 1 Debugging With the ChorusOS Operating System

This chapter provides an overview of the ChorusOS tools used for debugging applications developed for the ChorusOS operating system and for debugging the operating system itself. This chapter contains the following sections:

GDB and Insight for ChorusOS Systems

An application debugger enables you to see what is going on inside an application while it executes or what an application was doing at the moment it crashed. With a system debugger, it is possible to debug specific parts of an operating system. For ChorusOS operating systems, this includes the microkernel, the system drivers, the BSP, and certain supervisor actors. The GNU GDB Debugger for ChorusOS systems offers the following features:

Insight is a graphical user interface to GDB and provides access to most of GDB's capabilities. Insight is started by default when you start GDB.

Application Debugging Overview

Application debugging is used for debugging dynamically loaded applications, user applications and certain supervisor applications. It is not possible to debug the C_OS, the microkernel, or the system drivers with application debugging. When an application is debugged, only that application is affected. Other applications in the operating system, as well as the operating system itself, keep running.

Process Dump Overview

The Process Dump feature enables an application to be debugged post-mortem. This feature dumps a core image of a process as an ELF format file on unrecoverable faults or if pdump(2K) is invoked.

More than one process can be dumped by passing multiple process ID arguments. The generated core file is used by the debugging tool to perform a post-mortem analysis of the process.


Note -

The CORE_DUMP feature must be active for a core dump to be generated in the event of an application crash.


System Debugging Overview

System debugging is used for debugging specific parts of the ChorusOS operating system. This includes the microkernel, the system drivers, the BSP, and those supervisor actors that cannot be debugged with application debugging, such as the C_OS. System debugging also enables you to debug interrupt and exception handlers. During system debugging, the whole operating system is affected.


Note -

It is not possible to enable debugging information for the microkernel and the C_OS using the binary release of the ChorusOS operating system.


Enabling Symbolic Debugging

To use all the debugging features in the GDB debugging tool, you must generate symbolic debugging information when you compile components. This information is stored in object files and describes the data type of each variable or function and the correspondence between source line numbers and addresses in the executable code.

How you enable debugging in components depends on which release of ChorusOS 5.0 you have. The binary release of ChorusOS 5.0 includes the source code for the BSP, driver and example components. These are compiled in an imake build environment because the imake tool is used to create the Makefiles for these components.

The source release of ChorusOS 5.0 includes everything in the binary release plus source code for system components, such as the microkernel and the operating system. These components are built in a mkmk build environment where the mkmk tool is used to build Makefiles.

For more information about imake and mkmk, see "Using make and imake" in the ChorusOS 5.0 Application Developer's Guide.

Select one of the following to enable symbolic debugging:

Enabling Debugging for Components Built with imake

The following two procedures indicate how to enable symbolic debugging for components that have been built with imake.

To enable symbolic debugging throughout the component directory and its subdirectories
  1. Edit the Project.tmpl file.

    The Project.tmpl file is located in the root of the component directory. Add the following line to the end of the file:

    DEBUG=$(DEBUG_ON)

  2. Remove all the object files and executables.


    $ make clean
    

  3. Rebuild the local Makefile.


    $ make Makefile
    

  4. Rebuild the Makefiles in the subdirectories.


    $ make Makefiles
    

  5. Rebuild the component.


    $ make
    

To enable symbolic debugging in selected component directories
  1. Edit the Imakefile.

    Edit the Imakefile within each desired directory and add the following line to the end:

    DEBUG=$(DEBUG_ON)

  2. Remove all the object files and executables.


    $ make clean
    

  3. Rebuild the local Makefile.


    $ make Makefile
    

  4. Rebuild the component.


    $ make
    

If you prefer not to modify the Imakefile or Project.tmpl files, you can pass the debug option within the make command itself:

  1. Remove all the object files and executables:


    $ make clean
    

  2. Rebuild the component with symbolic debugging enabled:


    $ make DEBUG=-gdwarf-2
    

You can also create a DEBUG environment variable.

Call make with the -e option to import environment variables:


$ make -e

If the component is part of the system image, rebuild and reboot the system image.

Enabling Debugging for Components Built With mkmk

The following procedure describes how to enable symbolic debugging for system components built with mkmk.

To Enable Debugging for Componentes Built with mkmk
  1. Edit the definition file.

    Add the following line to the end of the specified *.df (definition) file:

    FREMOTEDEB=ON

  2. Remove all the object files and executables.


    $ make clean
    

  3. Create a new Makefile.


    $ make mkmk
    

  4. Rebuild the system component.


    $ make
    

Enabling Debugging for All Components

It is possible to build all components (those built with imake and those built with mkmk) with symbolic debugging information turned on. To do this, edit the Paths file, created when you run the configure command. The Paths file is located in build_dir.

Add the following line to the end of the file:

FREMOTEDEB=ON

Note -

This modification should be made just after running the configure command, otherwise it will apply only to newly compiled files.