Debugging Using SID

Aside from providing interactive monitoring of a simulation through a console or TK visual interface, SID provides mechanisms to debug and profile the simulation environment with conventional GNU development tools such as gdb and gprof. The following sections assume familiarity with these GNU tools, and focus on describing their interfaces with SID. The debugging and profiling components provided with SID are normal components, and certainly other such debugging and profiling components could be made. They do not have nor need special access to anything outside the normal SID component API; they merely serve as bridges between SID and other existing tools.

Using GDB

The debugging interface is designed resemble working with a remote "target board", using the GDB remote protocol. The SID simulation is run with a configuration that instantiates a sw-debug-gdb GDB stub component connected to a sid-io-socket-server socket component, which serves a connection between the GDB stub component and a remote debugger. The GDB stub component is configured to monitor and control other components within the simulation environment, such as CPU and system scheduler, in response to commands it receives from the socket component. A simulation user wishing to debug the simulation runs gdb as usual, on any machine capable of connecting to the host running the simulation, but directs it to the TCP socket configured into the socket component in the simulation. The user can then proceed to debug the simulation exactly as if it were a "real" target environment.

Configuring the GDB stub and socket components is somewhat lengthy and verbose, but is performed automatically by the configrun-sid command when invoked with the ---gdb=PORT option. For complete details of the connection process, see siddoc sw-debug-gdb.


The profiling facility consists of the standard GNU profile-analysis tool gprof, along with a SID component sw-profile-gprof. The component is loaded into a SID session and configured to sample any other component's numeric attribute, and record a histogram. The histogram is then output to a file, and gprof interprets the file as a "flat profile". The profiling component has no call-graph collection facility.

When the profiling component's sample pin is driven, it uses its value-attribute attribute as the name of an attribute to sample on the component in its target-component relation. The sample is taken immediately, interpreted as a numeric string, and stored in a histogram bucket. The histogram bucket's width, in bytes, is specified by the profiling component's bucket-size attribute.

When the profiling component's store pin is driven, the histogram is dumped to the file named in the profiling component's output-file attribute, which has a default value of gmon.out. The histogram is not cleared by this action, however. To clear the histogram, the profiling component's reset must be driven. Since dumping and resetting are separate operations, one can collect multiple cumulative profiles of a value across a single simulation run.

A simple configuration example is given below, showing a connection between the profiling component and a cpu (assumed to already be instantiated). For complete reference on the profiling component, see siddoc sw-profile-gprof.

Example 2. Profiling a CPU component's program counter

      load prof_component_library
      new sw-profile-gprof gprof

      relate gprof target-component cpu

      set gprof value-attribute pc
      set gprof bucket-size 4

      connect-pin main perform-activity -> gprof sample
      connect-pin main stopping -> gprof store