SourcePoint AMD Help
Table of Contents
- Using Help
- Contacting ASSET InterTech
- Introduction to SourcePoint
- SourcePoint Environment
- SourcePoint Overview
- SourcePoint Parent Window Introduction
- SourcePoint Icon Toolbar
- File Menu
- File Menu - Project Menu Item
- File Menu - Layout Menu Item
- File Menu - Program Menu Item
- File Menu - Macro Menu Item
- File Menu - Print Menu Items
- File Menu - Update Emulator Flash Menu Item
- File Menu - Program Target Device Menu Item
- File Menu - Other Menu Items
- Edit Menu
- View Menu
- Processor Menu
- Options Menu
- Options Menu - Preferences Menu Item
- Options Menu - Target Configuration Menu Item
- Options Menu - Load Target Configuration File Menu Item
- Options Menu - Save Target Configuration File Menu Item
- Options Menu - Emulator Configuration Menu Item
- Options Menu - Emulator Connection Menu Item
- Options Menu - Emulator Reset Menu Item
- Options Menu - Confidence Tests Menu Item
- Window Menu
- Help Menu
- How To -- SourcePoint Environment
- Add Emulator Connections
- Configure Custom Macro Icons
- Configure Autoloading Macros
- Display Text on the Icon Toolbar
- Edit Icon Groups to Customize Your Toolbars
- Modify a Defined Memory Region
- Refresh SourcePoint Windows
- Save a Program
- Start SourcePoint With Command Line Arguments
- Use the New Project Wizard
- Verify Emulator Network Connections
- SourcePoint Overview
- Breakpoints Window
- Breakpoints Window Overview
- How To - Breakpoints
- Code Window
- Command Window
- Command Window Overview
- Confidence Tests Window
- Confidence Tests Window Overview
- Descriptors Tables Window
- Descriptors Tables Window Overview
- How To - Descriptors
- Devices Window
- Devices Window Overview
- How To - Devices Window
- Log Window
- Log Window Overview
- Memory Window
- Memory Window Overview
- How To - Memory Window
- Page Translation Window
- Page Translation Windows Overview
- PCI Devices Window
- PCI Devices Window Overview
- How To - PCI Devices Window
- Registers Window
- Registers Window Overview
- How To - Registers
- Symbols Windows
- Symbols Window Overview
- How To - Symbols Window
- Viewpoint Window
- Viewpoint Window Overview
- Watch Window
- Watch Window Overview
- How To - Watch Window
- Technical Notes
- SourcePoint Command Language
- Overview
- Commands and Control Variables
- aadump
- abort
- abs
- acos
- advanced
- asin
- asm
- asmmode
- atan
- atan2
- autoconfigure
- base
- bell (beep)
- bits
- break
- breakall
- cachememory
- cause
- Character Functions
- clock
- continue
- cos
- cpubreak commands
- cpuid_eax
- cpuid_ebx
- cpuid_ecx
- cpuid_edx
- createprocess
- ctime
- cwd
- dbgbreak commands
- defaultpath
- #define
- define
- definemacro
- deviceconfigure
- devicescan
- disconnect
- displayflag
- do while
- dos
- dport
- drscan
- edit
- editor
- emulatorstate
- encrypt
- error
- eval
- evalprogramsymbol
- execution point ($)
- exit
- exp
- fc
- fclose
- feof
- fgetc
- fgets
- first_jtag_device
- flist
- flush
- fopen
- for
- forward
- fprintf
- fputc
- fputs
- fread
- fseek
- ftell
- fwrite
- getc
- getchar
- getnearestprogramsymbol
- getprogramsymboladdress
- gets
- globalsourcepath
- go
- halt
- help
- homepath
- idcode
- if
- include
- invd
- irscan
- isdebugsymbol
- isem64t
- isprogramsymbol
- isrunning
- issleeping
- issmm
- jtagchain
- jtagconfigure
- jtagdeviceadd
- jtagdeviceclear
- jtagdevices
- jtagscan
- jtagtest
- keys
- last
- last_jtag_device
- left
- license
- linear
- list, nolist
- load
- loadbreakpoints
- loadlayout
- loadproject
- loadtarget
- loadwatches
- log, nolog
- log10
- loge
- logmessage
- macropath
- Memory Access
- messagebox
- mid
- msgclose
- msgdata
- msgdelete
- msgdr
- msgdump
- msgir
- msgopen
- msgreturndatasize
- msgscan
- msr
- num_activeprocessors
- num_all_devices
- num_devices
- num_jtag_chains
- num_jtag_devices
- num_processors
- pause
- physical
- port
- pow
- print cycles
- printf
- proc
- processorcontrol
- processorfamily
- processormode
- processors
- processortype
- projectpath
- putchar
- puts
- rand
- readsetting
- reconnect
- Register Access
- reload
- reloadproject
- remove
- reset
- restart
- return
- right
- runcontroltype
- safemode
- save
- savebreakpoints
- savelayout
- savewatches
- selectdirectory
- selectfile
- shell
- show
- sin
- sizeof
- sleep
- softbreak, softremove, softdisable, softenable
- sprintf
- sqrt
- srand
- step
- stop
- strcat
- strchr
- strcmp
- strcpy
- _strdate
- string [ ] (index into string)
- strlen
- _strlwr
- strncat
- strncmp
- strncpy
- strpos
- strstr
- _strtime
- strtod
- strtol
- strtoul
- _strupr
- swbreak
- switch
- swremove
- tabs
- tan
- tapdatashift
- tapstateset
- targpower
- targstatus
- taskattach
- taskbreak, taskremove, taskdisable, taskenable
- taskend
- taskgetpid
- taskstart
- tck
- time
- #undef
- unload
- unloadproject
- upload
- unlock
- use
- verify
- verifydeviceconfiguration
- verifyjtagconfiguration
- version
- viewpoint
- vpalias
- wait
- wbinvd
- while
- windowrefresh
- wport
- writesetting
- yield
- yieldflag
Stepping
There are three commands (menu items, toolbar buttons, commands) for stepping: step into, step over, and step out of. These commands are described in detail below.
Step Into command. This single-steps the next instruction in the program and enters each function call that is encountered. This is useful for detailed analysis of all execution paths in a program.
Step Over command. This single-steps the next instruction in the program and runs through each function call that is encountered without showing the steps in the function. This is useful for analysis of the current routine while skipping the details of called routines.
Step Out Of command. This single-steps the next instruction in the program, and runs through the end of an existing function context. This is useful for a quick way to get back to the parent routine.
These commands may be interpreted in two ways, depending on whether source is available for the current execution location. If source debugging information is available for the current execution location, then it is possible to do a source-level step (step into or step over). A source-level step differs from a low-level or machine-level step by the range of addresses involved. In source-level stepping, the unit of interest is the source line (with its associated address range). In low-level stepping, the unit of interest is the machine instruction. For assembly code, source-level and low-level steps may be the same.
By using the stepping instructions in conjunction with the go/stop and breakpoint capabilities, a user may effectively track through the execution of programs.
Strategies for Source Level Stepping
Most compilers output debugging information at the level of the source line. This means that SourcePoint (or any other debugger for that matter) can source level step only a line at a time. Many languages allow the construction of multiple source statements on a single line. While this will not cause any difficulty in SourcePoint, for the purposes of stepping, it is a good idea to separate out as much functionality as possible onto separate lines.
For instance, the following C language source fragment will source level step as one statement:
Command input:
for ( i = 1, i < function1( 100 ), i++ ) { j = function2( i ); k += j; }
The intricacies of the internal execution of function1 and function2 will be missed. You could always step through the machine language generated by the compiler, but this is often quite time consuming and potentially confusing. The above C code might be rewritten as follows in order to step through the execution of function1 and function2 and the parts of the for block at the source level:
Command input:
for ( i = 1,
i < function1( 100 ),
i++ )
{
function2( i );
k += j;
}
This rewriting of the code will not affect the execution performance or effect, but will enable more effective debugging and perhaps a cleaner coding style. The rewriting is entirely optional. You might consider selective rewrites on certain parts of code that are to be debugged.
The writing of code compressed onto single lines applies to all source languages. The use of macros in assembly language, multiple statements on a line or defines in the C language, and similar constructions in other languages present the same difficulties in stepping. The debugger source level steps one source line at a time.
Stepping at source level or machine level
You can control whether stepping takes place at the source level or machine level via the Code window. If a single Code window is open, then the display mode of that window controls how stepping is performed. If the display mode is Source, stepping will take place at the source level. If the display mode is Mixed or Disassembly, stepping will take place at the machine level.
If multiple Code windows are open, the rules are more complex. The general rule is the Code window that is tracking the instruction pointer (has Track IP checked) and has the focus (contains the flashing cursor and has a highlighted title bar) determines the method of stepping. Situations where the Code window that has the focus is not tracking the instruction pointer may not conform to these rules. If the method of stepping is not as expected, switch focus to a Code window that is tracking the instruction pointer and select the desired display mode.
Step Into
The step into ability of the debugger can be invoked via a command, a toolbar button, or a menu item. This single-steps the next instruction in the program, and enters each function call that is encountered. This is useful for executing every path in a program.
Source Level Step Into
When the debugger performs a source level Step Into, machine instructions within the range of addresses defined by the source statement at the current point of execution are repeatedly executed until the point of execution lands outside the range. Upon execution of the source level step into function, the debugger first remembers the range of addresses for the source statement that contains the current execution point. Then, a machine-level step into is executed. The new execution point is determined. If the execution point is still contained within the range described by the source statement, then another machine-level Step Into is executed. This is repeated until either execution falls outside the range of the source statement or 255 steps have been executed. Note that 255 is the maximum number of steps allowed by the step command.
Machine Level Step Into
When the debugger performs a machine level Step Into, a machine instruction is executed. If executed via the menu or the toolbar, only one step is performed. If executed as a command (or macro), an optional repeat count is accepted. The repeat count can be between 1 and 255, inclusive. This causes the requested number of steps to be executed.
Step Over
The "step over" ability of the debugger can be invoked via a command, a toolbar button, or a menu item. This single-steps through instructions in the program. If this command is used when you reach a function call, the function is executed without stepping through the function instructions. This is useful for skipping over the execution of a subroutine and continuing with the execution of the current routine.
The step over capability may require the use of one of the four debug registers. It is always a good idea not to use all of the debug registers in breakpoints if you intend on using the Step Over command. If all of the debug registers are in use, a Step Over command will execute up to the point where the use of the debug register is required, and then it will stop with an error message dialog box.
Source Level Step Over
When the debugger performs a source level "step over," machine instructions within the range of addresses defined by the source statement at the current point of execution are repeatedly executed until the point of execution lands outside the range or a call is encountered. Upon execution of the source level Step Over command, the debugger first remembers the range of addresses for the source statement that contains the current execution point. Then, a machine-level Step Over command is executed. The new execution point is determined. If the execution point is still contained within the range described by the source statement, then another machine level Step Over command is executed. This is repeated until either execution falls outside the range of the source statement or 255 steps have been executed. Note that 255 is the maximum number of steps allowed by the Step command.
Machine Level Step Over
When the debugger performs a machine level "step over," one of two operations is performed. If the instruction at the current execution point is a call, a breakpoint is set after the call, and the target machine is given a Go command. All of the instructions in the subroutine called and any instructions recursively called will execute. The setting of a breakpoint requires the use of one of the four debug registers. If a debug register is not available, an error message will be displayed. If the instruction at the current execution point is not a call, a machine level "step into" is performed (see above). If executed via the menu or the toolbar, only one step is performed. If executed as a command (or macro), an optional repeat count is accepted. The repeat count can be between 1 and 255 inclusive. This causes the requested number of steps to be executed.
Step Out Of
Select the Step Out Of command to stop program execution at the next location after the return from the current function. This command places a breakpoint on the instruction immediately following the call instruction for the current routine. This is useful to skip over the rest of the current function and all calls made by the function. In the process of debugging, when you have determined that the current function does not contain the problem youโre looking for, this provides a rapid method of proceeding with debugging after the current function.
The Step Out Of command requires one hardware debug register for the breakpoint. If the resource is unavailable, this routine does not change anything and produces a beep.