keil调试过程查看全局变量和局部变量的方法及编译器优化

本文主要是介绍keil调试过程查看全局变量和局部变量的方法及编译器优化,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

keil调试过程查看全局变量和局部变量的方法及编译器优化

一、查看全局变量的方法:Watch Window

The Watch window allows to evaluate symbols, registers, and expressions. The window displays the item name, value, and type.
这里写图片描述Open this window through the toolbar button or using the menu View – Watch Windows.
这里写图片描述

Where

search boxAllows 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.
NameLists the expression name. Symbol names comply to the rules described in Program Variables (Symbols). Items are marked with an icon: Structure icon - identifies items of a complex type, such as structures or arrays. Simple icon - identifies items of a simple type, such as integers or characters.
ValueShows 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.
TypeShows 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]Open this window from the toolbar or using the menu View - Call Stack Window.

uv4_db_dbg_callstack[1]

Where

NameDisplays 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/ValueDisplays 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.
TypeShows 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:

  • 0

    Minimum 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 -O0 corresponds most closely to the source code, users may prefer the debug view produced by -O1 as 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.

  • 1

    Restricted 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 –O0 are: 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 –O1 produces 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.

  • 2

    High 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 –O1 are: 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.

  • 3

    Maximum optimization. When debugging is enabled, this option typically gives a poor debug view. ARM recommends debugging at lower optimization levels. If you use -O3 and -Otime together, 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=option controls 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 –Otime use the --remarks command-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.

这篇关于keil调试过程查看全局变量和局部变量的方法及编译器优化的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/968052

相关文章

PHP轻松处理千万行数据的方法详解

《PHP轻松处理千万行数据的方法详解》说到处理大数据集,PHP通常不是第一个想到的语言,但如果你曾经需要处理数百万行数据而不让服务器崩溃或内存耗尽,你就会知道PHP用对了工具有多强大,下面小编就... 目录问题的本质php 中的数据流处理:为什么必不可少生成器:内存高效的迭代方式流量控制:避免系统过载一次性

python获取指定名字的程序的文件路径的两种方法

《python获取指定名字的程序的文件路径的两种方法》本文主要介绍了python获取指定名字的程序的文件路径的两种方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要... 最近在做项目,需要用到给定一个程序名字就可以自动获取到这个程序在Windows系统下的绝对路径,以下

oracle 11g导入\导出(expdp impdp)之导入过程

《oracle11g导入导出(expdpimpdp)之导入过程》导出需使用SEC.DMP格式,无分号;建立expdir目录(E:/exp)并确保存在;导入在cmd下执行,需sys用户权限;若需修... 目录准备文件导入(impdp)1、建立directory2、导入语句 3、更改密码总结上一个环节,我们讲了

JavaScript中的高级调试方法全攻略指南

《JavaScript中的高级调试方法全攻略指南》什么是高级JavaScript调试技巧,它比console.log有何优势,如何使用断点调试定位问题,通过本文,我们将深入解答这些问题,带您从理论到实... 目录观点与案例结合观点1观点2观点3观点4观点5高级调试技巧详解实战案例断点调试:定位变量错误性能分

Python中 try / except / else / finally 异常处理方法详解

《Python中try/except/else/finally异常处理方法详解》:本文主要介绍Python中try/except/else/finally异常处理方法的相关资料,涵... 目录1. 基本结构2. 各部分的作用tryexceptelsefinally3. 执行流程总结4. 常见用法(1)多个e

ShardingProxy读写分离之原理、配置与实践过程

《ShardingProxy读写分离之原理、配置与实践过程》ShardingProxy是ApacheShardingSphere的数据库中间件,通过三层架构实现读写分离,解决高并发场景下数据库性能瓶... 目录一、ShardingProxy技术定位与读写分离核心价值1.1 技术定位1.2 读写分离核心价值二

MyBatis-plus处理存储json数据过程

《MyBatis-plus处理存储json数据过程》文章介绍MyBatis-Plus3.4.21处理对象与集合的差异:对象可用内置Handler配合autoResultMap,集合需自定义处理器继承F... 目录1、如果是对象2、如果需要转换的是List集合总结对象和集合分两种情况处理,目前我用的MP的版本

JavaScript中比较两个数组是否有相同元素(交集)的三种常用方法

《JavaScript中比较两个数组是否有相同元素(交集)的三种常用方法》:本文主要介绍JavaScript中比较两个数组是否有相同元素(交集)的三种常用方法,每种方法结合实例代码给大家介绍的非常... 目录引言:为什么"相等"判断如此重要?方法1:使用some()+includes()(适合小数组)方法2

504 Gateway Timeout网关超时的根源及完美解决方法

《504GatewayTimeout网关超时的根源及完美解决方法》在日常开发和运维过程中,504GatewayTimeout错误是常见的网络问题之一,尤其是在使用反向代理(如Nginx)或... 目录引言为什么会出现 504 错误?1. 探索 504 Gateway Timeout 错误的根源 1.1 后端

从原理到实战解析Java Stream 的并行流性能优化

《从原理到实战解析JavaStream的并行流性能优化》本文给大家介绍JavaStream的并行流性能优化:从原理到实战的全攻略,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的... 目录一、并行流的核心原理与适用场景二、性能优化的核心策略1. 合理设置并行度:打破默认阈值2. 避免装箱