Visible to Intel only — GUID: jvp1679710855902
Ixiasoft
Visible to Intel only — GUID: jvp1679710855902
Ixiasoft
6.4. Debugging Target Software with Symbol Files
An important part of a debugger's task is to understand the system being debugged at a higher level than just machine instructions and memory contents. You think in terms of processes, functions, and named variables, so the debugger presents a view of the software that matches these concepts. This view is even more important in the Intel® Simics® simulator, where you have access to the whole system and not only user processes. To handle this, the Intel® Simics® simulator provides only some primitive building blocks for basic debugging like context objects.
A context object represents a virtual address space. Each processor in the simulated system has a current context, which represents the virtual address space currently visible to code running on the processor. Virtual-address breakpoints are properties of contexts; different context objects have separate sets of virtual breakpoints, and by changing a processor's current context, you change its set of virtual breakpoints.
The correctness of the simulation does not depend on contexts in any way; the concept of multiple virtual address spaces is useful for understanding the simulated software, but not necessary for running it. What contexts to create and how to use them is entirely your business; Intel® Simics® simulator does not care.
By default, every processor in a simulation cell uses the same default context. You may create new contexts and switch between them at any time. This allows you, for example, to maintain separate debugging symbols and breakpoints for different processes in your target machine. When a context is used in this manner (active when and only when a certain simulated process is active), the context is said to follow the process.