This might not be important, but just a heads up.

They take the form:
void snap<NUM_SNAPS>_<ABS_ROM_ADDR>();
An example:
void snap10_08040000();

What this does, is that it is going to intercept at 0x08040000 (0x40000 in ROM), 10 times, for 10 different assembly instructions.
When intercepting, the logic at that instruction has to be modified to include branching logic. This must be accounted for to determine where the next instruction is, so that another intercept occurs there.

Basically, for every one instruction run in a function, it will be intercepted by the logic in the snapshot function. This can be useful to view a (almost complete) state view of the intercepted function. This can be very useful for diagnostics.

This is because they are treated differently in the combined relocatable object file.
They do not have a type OBJECT like other global variables. They have a type of NOTYPE.
Further, function static variables also have a strange syntax to their naming. .4158 for example, or something similar. That needs to be decoded to figure out how to deal with those variables.

Interceptor functions that inject into the ROM both their logic AND and where they are to be called.
They intercept other functions by adding assembly code for their execution inside the calling function.
When they are executed, they contain the assembly code that has been overwritten from the caller function to call them. This way, they wouldn't corrupt the calling function. Their original content would be directly after the overwritten content.

In the C file, an interceptor function takes the form of:
intercept_<ABS_ROM_ADDR>()
For example:
void intercept_08040000(); Would declare that the intercepting logic be executed at the address 0x40000 in ROM, and the actual location of the function would be located by the linker.

Report where variables are stored/ change format. Make the mechanism for reporting more versatile as its own module.