This release contains a number of major upgrades and changes to the debugger. Huge portions of the debugger have been majorly overhauled, and some portions have been rewritten. These major changes have been made to improve the debugger long-term, and many debugger systems have become more stable, but as with any set of major changes like this, instabilities and new regressions may occur. Thank you for your patience in dealing with those issues. If you happen to find some, please be sure to report them.

IMPORTANT NOTE: This release contains many changes to the configuration file format. Because the debugger is in alpha, and because the relationship between new configuration files and old is not one-to-one, I deemed it low-value to invest a lot of time in preserving all configuration data from earlier versions. Thus, only a small subset of information within old configuration files is preserved when loaded in the 0.9.16 debugger (targets and file path maps, notably). Other information will be lost. Because of this, I recommend backing up your configuration files for the 0.9.15 debugger if they contain useful data to you. That will also be useful if the new version has currently-uncovered instabilities, and you'd like to continue using 0.9.15 until those are resolved.

Below are the list of the most important changes:

Debugger Changes

• Formal integration of views (view rules) into the evaluation language. "View rules", now simply called "views", have been formally integrated into the debugger evaluation language. They now appear similar to function calls, and are expressed directly within an expression. For example, an expression dynamic_array with a view rule slice from prior versions would now be expressed as slice(dynamic_array). Alternatively, views can be expressed with similar syntax to method calls: dynamic_array.slice(). Many views can still be attached to a single expression, like dynamic_array.slice().hex() (equivalent to hex(slice(dynamic_array)). The first argument to a view is the expression to which the view should apply. Some views take additional parameters, like bitmap(base_pointer, width, height). Named parameters, required in some cases (e.g. the fmt/format parameter for bitmap), are expressed using name = value syntax: bitmap(base, width, height, fmt=bgra8).
• Support for generics in type views (auto view rules). "Auto view rules", now simply called "type views", have been upgraded to support type pattern-matching. This makes them usable for generic types in various languages. This pattern-matching is done by using ? characters in a pattern, to specify placeholders for various parts of a type name. For example, the pattern DynamicArray<?> would match DynamicArray<int>, DynamicArray<float>, and so on. ?(?) would match all function types. (#118, #345)
• Usage of the source expression within type views. Type views have been upgraded to support a larger number of possibilities. Instead of mapping to a set of views which are applied to some other expression, type views can remap the expression itself, and apply additional views. These expressions can refer to the originating expression either explicitly using the $ character, or implicitly in some cases. For instance, a type like struct Bitmap {U8 *base; U32 width; U32 height;}; can be used in a type view which maps Bitmap to bitmap(base, width, height). In this case, base, width, and height are recognized as being member names of Bitmap. This is equivalent to bitmap($.base, $.width, $.height).
• Hardware data breakpoints. Breakpoints have been upgraded to support flags for breaking on writing, reading, or execution, as well as an address range size. When used with an address location, this can be used to express hardware data breakpoints, where the CPU will break when it sees particular addresses being written to, read from, or executed, regardless of which code does it. There is a maximum limit of four such breakpoints on a processor. Theoretically, this means a limit of four per thread, but for now, the debugger only supports four global data breakpoints. In the future, we plan to allow organizing these by thread, in which case the total number of data breakpoints we support will increase.
• A new table view has been added, which allows one to define custom rules for how rows of a watch expansion are formed. The first argument a table is the expression which should be evaluated (like other views), and the remaining arguments are used to express a number of expressions which should be used to generated cells for each row in the expansion. For instance, table(my_int_array, $, $*4, $*8) would expand my_int_array, but instead of the default row structure (which displays an expression string, a value string, and a type string), three cells would be generated per row: one with the value of each element, one with that value multiplied by 4, and one multiplied by 8.
• A new sequence view has been added. This is a simple view which simply takes a single integer scalar argument n, and returns a sequence of integers, from 0, 1, 2, all the way to n. This sequence can be expanded. This can compose with the table view, to easily generate n rows, and use each integer as a value in each cell expression. As an example, table(sequence(1000), array1[$], array2[$]) would display elements of array1 and array2 in each row, side-by-side.
• The everything palette. The F1 command palette has been replaced by a substantially more powerful "everything palette" (referred to in the UI simply as "palette"), opened with the Open Palette command. This palette lists commands and allows the editing of bindings, just like the old command palette (although it now also supports searching for command bindings themselves, in addition to the original searching support for command names and descriptions). However, this palette now also lists targets, breakpoints, recent files, recent projects, settings (including tab settings, window settings, user settings, project settings), attached processes, threads, modules, functions, types, and global variables. This can be used to quickly search for a large set of possible things, and either jump to them or edit them. The old Run Command command still exists, and still presents a command palette, which is simply a special-case of the generalized palette. But this command is no longer bound to F1 by default.
• Upgraded per-tab settings. The tab right-click menu has been upgraded to show all tab-related settings, including ones specially-defined for specific visualizers (like the width and height parameters to the bitmap visualizer). The debugger UI now also supports per-tab font sizes. If a tab has no per-tab font size set, then it inherits the window's font size. Each tab's root expression is now also editable in this interface. The tab right-click menu's options also show up in the palette when the corresponding tab is focused. They can also be manually opened with the Tab Settings command.
• UI for setting fonts. The fonts which the debugger uses can now be set through settings UI (including the palette), rather than just through the configuration files.
• Support for searching system font folders for fonts. The debugger now accepts system font file names in addition to full font file paths to specify font settings.
• Per-Watch expressions and labels. Expressions inserted into a Watch tab are now stored per-tab. This makes many Watch tabs more useful, since different tabs can have a different set of expressions. Watch tabs can now also be labeled, so you can visually distinguish many Watch tabs more easily.
• Evaluation drag/drop. Evaluations in a watch tree can be dragged and dropped. This can be used to create new top-level rows in a Watch tab, or to drag evaluations between Watch tabs, or to drag evaluations to source or disassembly views and pin the evaluation to some location there. (#137, #388)
• Settings expressions. Debugger settings have been upgraded to be stored as expressions, rather than being locked to a specific value. These expressions are evaluated, like any other expression, and their evaluated value is used when the setting value is actually needed.
• Upgrades to the slice view. The slice view has been streamlined and simplified. When an expression with a slice view is expanded, it will simply expand to the slice's contents, which matches the behavior with static arrays. The slice view now also supports first, one_past_last pointer pairs, as well as base_pointer, length pairs.
• Boolean evaluation toggle-switches. The debugger now displays toggle switches as an additional visualization and editor for all boolean evaluations.
• A new range1 view has been added, which expresses bounds for some scalar value. When this view is used in an evaluation, the debugger will visualize the evaluation value with a slider, which can be used to edit the value as well.
• Merging of Watch UI with hover evaluation. The hover evaluation feature has been majorly upgraded to support all features normally available in Watch tabs. (#342)
• Added transient tabs, which are colored differently than normal tabs. These tabs are automatically opened by the debugger when snapping to source code which is not already opened. They are automatically replaced and recycled when the debugger needs to snap to new locations. This will greatly reduce the number of unused source code tabs accumulated throughout a debugging session. These tabs can still be promoted to permanent tabs, in which case they'll stay around until manually closed.
• The Scheduler tab has been removed, in favor of three separate tabs, which present various versions of the same information: Threads, Processes, and Machines. The justification for this is that the common case is debugging a small number of programs, usually 1, and for those purposes, the Threads tab is sufficient if not desirable, and the extra information provided by Processes and Machines, while useful in other contexts, is not useful in that common case. The Machines tab now shows a superset of the information previously found in the Scheduler tab.
• The two separate interfaces for editing threads, breakpoints, and watch pins (the right-click context menu and the dedicated tabs) have been merged. Both interfaces support exactly the same features in exactly the same way. The same interface is also accessible through the palette.
• Added the ability to add a list of environment strings to targets. (#73)
• The debugger releases are now packaged with a raddbg_markup.h single-header library which contains a number of source code markup tools which can be used in your programs. Some of these features are for direct interaction with the RAD Debugger. Others are simply helpers (often abstracting over platform functionality) for very commonly needed debugger-related features, like setting thread names. This second set of features will work with any debugger. Here is a list of this library's initial features (proper documentation will be written once the library matures):
  • raddbg_is_attached(): Returns 1 if the RAD Debugger is attached, otherwise returns 0.
  • raddbg_thread_id(): Returns the calling thread's ID.
  • raddbg_break(): Generates a trap instruction at the usage site.
  • raddbg_break_if(expr): Generates a trap instruction guarded by a conditional, evaluating expr.
  • raddbg_log(format, ...), e.g. raddbg_log("This is a number: %i", 123): Writes a debug string for a debugger to read and display in its UI.
  • raddbg_thread_name(format, ...), e.g. raddbg_thread_name("worker_thread_%i", index): Sets the calling thread's name.
  • raddbg_thread_id_name(id, format, ...), e.g. raddbg_thread_name(thread_id, "worker_thread_%i", index): Sets a thread's name by thread ID.
  • raddbg_thread_id_color_u32(hexcode), e.g. raddbg_thread_id_color_u32(thread_id, 0xff0000ff): Sets a thread's color by thread ID.
    • Also can be done with individual [0, 1] color components: raddbg_thread_id_color_rgba(thread_id, 1.f, 0.f, 0.f, 1.f)
  • raddbg_pin(<expr>), e.g. raddbg_pin(slice(dynamic_array)): Like watch pins, but defined in source code. This is used by the debugger UI, but does not show up anywhere other than the source code, so it can either be used as a macro (which expands to nothing), or in comments too.
  • raddbg_entry_point(name), e.g. raddbg_entry_point(entry_point): declares the entry point for an executable, which the debugger will use when stepping into a program, rather than the defaults (e.g. main).
  • raddbg_type_view(<type|pattern>, <expression>), e.g. raddbg_type_view(DynamicArray<?>, slice($)): declares a type view from source code, rather than from debugger configuration.
• The debugger now incorporates the loaded project in all window titles.
• The debugger now supports per-project themes (as well as per-user themes). Each window has a setting which determines whether or not the user or the project theme is used for that window.
• Fixed an annoyance where the debugger would open a console window, even for graphical programs, causing a flicker.
• Fixed substantial unnecessary memory usage with very large output logs.
• Fixed a debugger regression which was incorrectly using thread name events when those events were sent to name a suspended thread by a different thread. (#430)
• Added support for Tab and Shift + Tab style navigation in Watch tables, using the Move Next and Move Previous commands. (#93)
• The debugger now correctly serializes window sizes when fullscreened. (#130)
• Added an option to disable the Alt key Windows-style menu-bar focusing behavior. (#382)
• Added an option to quickly duplicate configuration entities (targets, breakpoints, etc.). (#451)
• Fixed a crash relating to truncated string hover tooltips when font sizes were changed. (#416)
• Fixed the debugger's lack of robustness to selecting non-config files as config files. (#432, #409)
• Fixed crashes caused by quick changes in the set of loaded modules while debug information table tabs (Procedures, Globals, Types) were open. (#467, #459, #458, #440, #436, #415, #412)
• Fixed a crash where the debugger would crash when toggling fullscreen, if launched in fullscreen mode. (#454, #413)
• Adjusted breakpoint placement to automatically deduplicate identical breakpoints, if placed at the same location, with no extra information attached (condition or label). (#407)
• Made several visual improvements.

Linker Changes

The linker in this release is unchanged since 0.9.15.