At this point in time, many unit (and some integration) tests rely on checking for specific addresses to validate the output of different parts of the debugger. This is problematic because if the addresses in one of the example binaries used in testing change just a bit, the tests that expect them will fail. Those failures will usually be false negatives, since it's just the binary that contains a different address after compiling again.

An obvious solution that comes to mind is to compile all the examples once and check them into version control. This way they would stay the same no matter what machine the tests
run on. This approach has the disadvantage that the range of different compilers and platforms tests is much more narrow. Specifically the tests will exclusively make assertions about the platform they were once compiled on.

In the integration tests, regular expressions might be used to check that there are addresses at the right positions. The downside of this is that any address will be accepted. Since all addresses passed around internally have their own address type anyways, the type system already enforces the presence of addresses. Hence, this solution decreases the value of the assertions drastically, too.

Lastly, we could assert that any given address must be in a specific (narrow) range. I've seen multiple tests fail because of off-by-one assertions where the new address was only slightly different.

This is definitely still an open problem and I'd be happy to discuss different options.

I see you are using Chicken Scheme for C processing. I recommend taking a look at Tree-Sitter, it has many grammars, including C one:

• https://tree-sitter.github.io
• https://github.com/tree-sitter/tree-sitter
• https://github.com/tree-sitter/tree-sitter-c

Here you can see how different queries work with TS, including highlighting: https://github.com/nvim-treesitter/nvim-treesitter/tree/master/queries/c

• is_dyn_exec in src/info.c ought not to return false if info is NULL. Just crash, otherwise totally wrong data is passed around.
• parse_num (src/debugger.c) will segfault if passed NULL in its first argument. The function should check that this argument is not NULL.

If the child process ("tracee") exists, the REPL continues and signals an error every time one tries to step through the program (because the child process cannot step anywhere).

Instead of this behavior, the REPL should (for example) exit once the child exists, or drop into some state from which the child process can be restarted.

A lot of DWARF debug information is encoded as programs for a stack-based VM. Without turning on optimizations, only very few of the operations that exist for this VM are used in the debug information produced by Clang. Turning on optimizations seems to break multiple assumptions that Spray currently makes for analyzing programs at runtime.

To implement (and test) more VM operations, a method of producing reference binaries that use these operations is needed that doesn't rely on turning up the optimization level. Without reference binaries, it doesn't make sense to add implementations to the missing operations.

The current approach to finding the DIE that contains runtime information about a variable (by the variable's name) consists of two steps:

1. We continually narrow the range of potential DIEs until we end up in a range that can only contain the variable we are looking for once (i.e., the scope of the function that contains the given PC)
2. If no such range could be found, we traverse the entire DIE tree again, this time ignoring scope and choosing the first occurrence we find.

(This is implemented in the sd_runtime_variable function in src/spray_dwarf.c. It's documented here)

The problem of this top-down approach is that it's opposite to how variable scopes work. At any point in the program, when trying to access a variable, the closest one to the instruction pointer (PC) should be selected.

It appears that the current approach word fine (so far) for C because, in C, functions are not nested. This means that we are usually limited to two types of variables: those in the global scope and those in the current function.

The more general and reliable approach would be to build up a new tree of potential variables from the DIE tree and then traverse this variables tree, starting at the point closest to the given PC. If code blocks create new variable scopes, this would likely be the more correct approach (I haven't checked if nested {} blocks are reflected in the DWARF info at runtime).

TODO

• Find out how re-declaring variables and shadowing in nested scopes (e.g., {int a; {int a;}}) is reflected in DWARF info.
• Find a concrete example of how the current approach fails. Use it as a test.
• Act like inlining doesn't exist ... 🤫

src/spray_dwarf.h:17:10: fatal error: 'libdwarf-0/libdwarf.h' file not found
#include <libdwarf-0/libdwarf.h>
^~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:43: build/info.o] Error 1

P.S. My system: Manjaro(Linux 6.6.8-2-MANJARO)

A few notes on implementing potential roadmap features.

• It would be cool if inlined function were allowed. As a place to start, there is a short mention of inlining in this post: "With inlining, for example, once we’ve found the function whose range contains our PC, we’ll need to recurse over the children of that DIE to see if there are any inlined functions which are a better match."
• Add multi-word memory read and write using process_vm_readv(2). The implementation would live in src/registers.c.