DebugEval

Introduction

This test program does not show any feature of the Oberon RTK framework, but simply serves as basis to introduce some intermediate results of the side-project of creating debugging facilities using the on-chip debugging features of the RP2040.

Note that the new tool used here requires an edition of Astrobe for Cortex-M0 that provides the disassembly functionality for single modules and the whole program, namely the Personal or Professional Edition, but not the Starter Edition.

Overview

The RP2040, as many other ARM-based MCUs, have basic debugging features built right into the chip (OCD). Examples are breakpoints, watchpoints, single-stepping, inspection of registers and memory, and so on. While we can often use printing to the terminal to follow the programmed logic for testing, or in case it does not behave as intended, this method falls short in the context of real-time logic, where the timing counts, and printing is simply too slow, and distorts the results.¹ Also, for automated testing, it’s better not to rely on printed output.

The side-project “OCD for Oberon RTK” evaluates if, and how, the on-chip features of the RP2040 could be employed for real-time debugging of Oberon control programs. This document describes a few first results, which are extended assembly listings of both the modules (after linking) and the whole program.

Why such listings? Source code level debugging is out of reach without compiler and linker support to create comprehensive symbol tables and debug data (eg. DWARF). Hence, assembly level debugging. For this, assembly listings with added information about the source code that is useful for debugging are useful. Also, with assembly level debugging, the main reference is the absolute address, of both code and data. Hence the motivation to have listings with absolute addresses. Since I am bad at reading assembly code, I need all the help I can get that helps me understanding and follow along.

The Test Program

The test program DebugEval.mod is a simple two threads application, blinking some LEDs and writing to the terminal. Also, there’s quite some “junk code” and silly comments, in order to evaluate how Astrobe structures its outputs, and to test if my tools read and handle that output well.

The Extended Assembly Listings

Information Source

All data and information is read and extracted from:

• the modules’ .lst files, created after the compilation by the module disassembler at compile time,
• the program’s .map file, created by the linker at build time,
• the program’s .asm file, created after the linking by the program disassembler at build time.

Directory

The generated extended listing files are in the directory ./rdb inside the project directory. Normally, I would not keep generated files in the repository, but include them for this example program for your reference, since that’s the only takeaway from this example program. :)

Extended ‘.elst’ Files (Modules)

Extensions compared to each module’s .lst file:

• absolute code and RAM addresses after linking
• that is, linker references have been resolved
• show as called procedures as ModName.ProcName, in lieu of Ext Proc #
• references to code addresses to look up values directly show the values (constants, RAM addresses)

Note: the module-relative address is still included in the first column.

Extended ‘.easm’ File (Program)

Extensions compared to the program’s .asm file:

• Oberon source code
• constant .word values are annotated: Global, Const, Type, etc.
• references to code addresses to look up values directly show the values (constants, RAM addresses)

Remarks

• Both extended listing file types display nicely in Astrobe’s viewer. In particular, for the .easm file, the left hand pane shows the list of all procedures.
• Not sure yet if the presentation of the source code in the .easm file is useful, in particular for the modules’ .init procedures and the end of the module itself, as well as the procedure declarations as ModName.ProcName, which is not even valid Oberon code.² I may simplify this, and just use the modules as “separation headers”, as in the .asm files.
• The file extensions .elst and .easm may change.

The Tool ‘rdb’

Use

Here’s how I have used the tool rdb to create the above extended listings.

In Astrobe:

• Project > Build, and
• Project > Disassemble Application

Inside the project directory:

python -m rdb init
python -m rdb update DebugEval

Running

python -m rdb -h

usage: rdb [-h] [-v] {init,update,clean} ...

options:
  -h, --help           show this help message and exit
  -v                   verbose, print feedback

commands:
  {init,update,clean}
    init               create debug file directory and config file
    update             update or generate all debug files
    clean              remove all generated files

Performance

The update command for the example program takes about 350 ms on my three years old Windows PC (AMD 5600X, 6 cores, 3.6 GHz, 32 GB RAM). Acceptable.

Concept

Running rdb update DebugEval, the tool

1. collects data from the above source files into a “metadata database”, hierarchically structured into data pertaining to
   • the program,
   • the modules,
   • the procedures,
2. patches the data
   • using program data to extend module data, and vice versa,
   • using data inside the same data set,
3. creates the .elst and .easm files from the data.

The database it quite fine-grained. For example, each line of assembly code is kept in its own record.

Repository

• DebugEval.mod
• DebugEval/rdb