keil调试过程查看全局变量和局部变量的方法及编译器优化
一、查看全局变量的方法：Watch Window
The Watch window allows to evaluate symbols, registers, and expressions. The window displays the item name, value, and type.
Where
| search box | Allows finding expressions within the current name list. The search string can consist of alphanumeric characters and mask characters as described in the appendix F. TR1 Search Expressions. |
|---|---|
| Name | Lists the expression name. Symbol names comply to the rules described in Program Variables (Symbols). Items are marked with an icon:  - identifies items of a complex type, such as structures or arrays.  - identifies items of a simple type, such as integers or characters. |
| Value | Shows the memory address or the evaluated value of an expression. This field can contain explanatory text. Expressions of the type unsigned char show the value and the corresponding character. A single-quote (‘) indicates that the value was restored from a previous debugging session. Values are updated: Whenever program execution stops. During program execution when View - Periodic Window Update is enabled. When clicking the Toolbox button Update Windows. |
| Type | Shows the type of the expression. For functions the field shows the return and parameter types. |
Using the Watch Window
Drag&drop expressions to other windows, for example to a Memory, Command, or Logic Analyzer window.
Add an Expression
- Double-click the text and start editing. Refer to the section Expressions for details.
- Drag&drop expressions from other windows into the Watch window.
- Open the context menu of a file. Use Add item to - Watch #. The variable beneath the mouse position is added to the Watch window.
- Use the command WatchSet in the window Command.
Remove an Expression
- Click on the item name and press the Delete key.
- Use the command WatchKill in the window Command.
Change the Value of an Expression
- Click on the value-field and start editing. Not all expressions accept changes.
The context menu allows:
- Removing an expression.
- Changing the value representation.
- Setting breakpoints.
- Adding expressions to other windows.
- Showing or hiding the toolbar that contains the search box.
二、查看局部变量的方法：Call Stack and Locals Window
The Call Stack + Locals window shows objects that are currently on stack. Tasks are shown for applications that use the RTX-RTOS. Each object is associated to its location or value, and type.
![b_uv4_callstack_window[1]](D:\Documents\Downloads\b_uv4_callstack_window[1].png)
Open this window from the toolbar or using the menu View - Call Stack Window.
![uv4_db_dbg_callstack[1]](D:\Documents\Downloads\uv4_db_dbg_callstack[1].png)
Where
| Name | Displays the symbol names. The currently active function or task is highlighted in green. Double-click the item node to expand or collapse the item. |
|---|---|
| Location/Value | Displays the memory address or value of the item, or has an explanatory text. For items of the type unsigned char the field shows the value and the character. |
| Type | Shows the object type. Functions are associated with their return type and parameter types. |
The window content is updated automatically:
- Whenever program execution stops.
- During program execution when View - Periodic Window Update is enabled.
The context menu allows:
- Jumping to the caller code.
- Jumping to the callee code.
- Switching between the hexadecimal and decimal representation of values.
三、编译器优化：Compiler optimization levels and the debug view
The precise optimizations performed by the compiler depend both on the level of optimization chosen, and whether you are optimizing for performance or code size.
The compiler supports the following optimization levels:
0Minimum optimization. Turns off most optimizations. When debugging is enabled, this option gives the best possible debug view because the structure of the generated code directly corresponds to the source code. All optimization that interferes with the debug view is disabled. In particular: Breakpoints may be set on any reachable point, including dead code. The value of a variable is available everywhere within its scope, except where it is uninitialized. Backtrace gives the stack of open function activations which are expected from reading the source. Note Although the debug view produced by
-O0corresponds most closely to the source code, users may prefer the debug view produced by-O1as this will improve the quality of the code without changing the fundamental structure. NoteDead code includes reachable code that has no effect on the result of the program, for example an assignment to a local variable that is never used. Unreachable code is specifically code that cannot be reached via any control flow path, for example code that immediately follows a return statement.1Restricted optimization. The compiler only performs optimizations that can be described by debug information. Removes unused inline functions and unused static functions. Turns off optimizations that seriously degrade the debug view. If used with
--debug, this option gives a generally satisfactory debug view with good code density. The differences in the debug view from–O0are: Breakpoints may not be set on dead code. Values of variables may not be available within their scope after they have been initialized. For example if their assigned location has been reused. Functions with no side-effects may be called out of sequence, or may be omitted if the result is not needed. Backtrace may not give the stack of open function activations which are expected from reading the source due to the presence of tailcalls. The optimization level–O1produces good correspondence between source code and object code, especially when the source code contains no dead code. The generated code will be significantly smaller than the code at–O0, which may simplify analysis of the object code.2High optimization. If used with
--debug, the debug view might be less satisfactory because the mapping of object code to source code is not always clear. The compiler may perform optimizations that cannot be described by debug information. This is the default optimization level. The differences in the debug view from–O1are: The source code to object code mapping may be many to one, due to the possibility of multiple source code locations mapping to one point of the file, and more aggressive instruction scheduling. Instruction scheduling is allowed to cross sequence points. This can lead to mismatches between the reported value of a variable at a particular point, and the value you might expect from reading the source code. The compiler automatically inlines functions.3Maximum optimization. When debugging is enabled, this option typically gives a poor debug view. ARM recommends debugging at lower optimization levels. If you use
-O3and-Otimetogether, the compiler performs extra optimizations that are more aggressive, such as: High-level scalar optimizations, including loop unrolling. This can give significant performance benefits at a small code size cost, but at the risk of a longer build time. More aggressive inlining and automatic inlining. These optimizations effectively rewrite the input source code, resulting in object code with the lowest correspondence to source code and the worst debug view. The--loop_optimization_level=optioncontrols the amount of loop optimization performed at–O3 –Otime. The higher the amount of loop optimization the worse the correspondence between source and object code. For extra information about the high level transformations performed on the source code at–O3 –Otimeuse the--remarkscommand-line option.
Because optimization affects the mapping of object code to source code, the choice of optimization level with -Ospace and -Otime generally impacts the debug view.
The option -O0 is the best option to use if a simple debug view is required. Selecting -O0 typically increases the size of the ELF image by 7 to 15%. To reduce the size of your debug tables, use the --remove_unneeded_entities option.