Classical ``address tracing'' gathers a list of instruction and/or data memory references performed by a system. There are many variations, such as tracing only targets of control transfers or tracing other resources.
A simulator can help with debugging because: it runs deterministically and repeatably; it is possible to query system state without disturbing it; the simulator can be backed up to an earlier checkpoint in order to implement reverse execution (``foo is twelve ... what was the value of bar in the routine we just returned from?''); and because a simulator can perform consistency checks that cannot be done on real hardware.
A generalization of address tracing is to trace, count, or categorize events on any kind of processor or system event or resource. For example, a tool may collect the common values of variables; register usage patterns; interrupt or exception event counts, timing information, and so on.
Simulators commonly implement a processor architecture that does not yet or no longer exists. Simulators can also implement other devices such as memory, bus, I/O devices, user input, and so on.
Here, ``tool building'' is meant to encompass tools that are used to build other tools, for example, a tool that builds various tracing tools is a tool-building tool, whereas a configurable cache simulator is not. The usual distinction is that a tool-building tool can be extended [NG87, NG88] using a general-purpose programming language (e.g. C, C++, ...), whereas a configurable tool is programmed with a less-powerful language e.g. a list of cache size, line size, associativity, etc.
Compare OS emulation ``as a purpose'' with simulators that emulate the OS for simplicity (see system-mode simulation or tracing).