27.2 Debugging the Analyzer

27.2.1 Builtins for Debugging the Analyzer

Add:

  __analyzer_break ();

to the source being analyzed to trigger a breakpoint in the analyzer when that source is reached. By putting a series of these in the source, it’s much easier to effectively step through the program state as it’s analyzed.

__analyzer_dump ();

will dump the copious information about the analyzer’s state each time it reaches the call in its traversal of the source.

__analyzer_dump_path ();

will emit a placeholder “note” diagnostic with a path to that call site, if the analyzer finds a feasible path to it.

The builtin __analyzer_dump_exploded_nodes will dump information after analysis on all of the exploded nodes at that program point:

  __analyzer_dump_exploded_nodes (0);

will dump just the number of nodes, and their IDs.

  __analyzer_dump_exploded_nodes (1);

will also dump all of the states within those nodes.

region_model::get_value_by_name can be used when inserting custom debugging code (e.g. adding it region_model::validate to detect the point at which a named variable acquires an unexpected state).

27.2.2 Other Debugging Techniques

One approach when tracking down where a particular bogus state is introduced into the exploded_graph is to add custom code to region_model::validate.

For example, this custom code breaks with an assertion failure when a variable called ptr acquires a value that’s unknown:

    /* Find a variable matching "ptr".  */
    svalue_id sid = get_value_by_name ("ptr");
    if (!sid.null_p ())
      {
	svalue *sval = get_svalue (sid);
	gcc_assert (sval->get_kind () != SK_UNKNOWN);
      }

making it easier to investigate further in a debugger when this occurs.