-
Notifications
You must be signed in to change notification settings - Fork 0
Debugging
IMHO one of the biggest differences I saw going from Motorola to Intel in the 1990s is at Intel really placed a high value on debuggability. Some of the DEC Alpha people made the same observation, when Intel absorbed their group. Apparently some of the DEC Alphas, although cool, had bugs that delayed their release.
Debuggability matters, not just for software developers on your CPU. Perhaps the most important reason it matters for a company that makes processors, CPUs, GPUs, systems, SOC's, is debugging the hardware.
- Debugging the hardware&software inside the company
- before it is built, e.g. on FPGAs (pre-silicon)
- after it's built, but before it ships to the general public (post-silicon, pre-commercial-release)
- after general release, when flaky, hard to reproduce, are reported in the field
- Debugging the hardware&software, with early customers
- both pre- and post-silicon: early customers may receive SW simulators, FPGAs, or silicon before general release
- Debugging not just the processors. Also the fabrics, the bus interfaces, ...
Debuggability reduces the TTM (Time To Money) for a processor vendor. And indeed, for platform, hardware, and software developers.
There are 2 main points of view for debuggers:
External hardware debugging, e.g. with something like an ICE (In Circuit Emulator), or perhaps just a few wires to signal taken/not taken branches. These trace signals being sucked off to external hardware, not standard system memory, typically built out of fast logic so that it can absorb the signals. Typically with some way for the external hardware debugger, e.g. on an external PC, to stop, query and set the system under test for register state, DRAM state, etc.
The external hardware debugger may stop/query/set the system under test
- e.g. by using something like JTAG to shift state in and/or out
- or higher-speed more powerful scan systems
- or by having a debug mode that executes instructions on the processor itself
- possibly in a standard debug ROM
- possibly in a debug RAM
- whose contents may have been scanned in
- or possibly written by normal DRAM access, although probably not when the system under test is running at full speed
Internal software debugging is the sort of debugging that a normal user or OS developer will do. E.g. on the UNIX command line, "gdb program...". It may be restricted only to debug a particular user processes' code (although if run by OS or hypervisor developers it may have broader access privileges). It typically does not have a special debug mode, historically running either inside the kernel or hypervisor (or, better, in a microkernel like situation in a process that is part of the kernel or hypervisor but which is not maximally privileged, with callbacks to perform privileged accesses).
However, there is a spectrum here.
For example, Intel SMM (System Management Mode) could be used to do OS independent debugging, largely in software.
TBD: does this GitHub wiki have any way of producing in-line links to a section at the bottom of the page that links externally? I.e. automatic local inline indirect links, rather than me having to set it up myself.
I started writing this page mainly to hold links to such documents.
- Intel Last Branch Records
- tracing to a very limited number of internal registers (MSRs)
- Intel PT (Processor Trace) and RTT (Realtime Instruction Trace) https://software.intel.com/en-us/system-debug-legacy-user-guide-rtit-pt-trace
- tracing to system memory
- TBD: to summarize and post
TBD: ARM debug features
TBD: Intel 46 era [[ICE (In Circuit Emulation) mode
- notorious because the ICE instruction, not documented for normal users, turned out to be a security hole
TBD: other companies: Motorola/FreeScale, IBM, POWER,