Method to enable macros debugging
Publication Date: 2010-Dec-01
The IP.com Prior Art Database
This invention is a method to enable macros debugging. Users can get the value of macros or set value to macros (if applicable) when debugging a program which is compiled from the source code containing macros. The method presented in this invention can enable developers to debug macros more conveniently and efficiently. The functions provided by this method includes: 1) display static information about a specific macro 2) import macros defined in the debuggee program into the debugger as debugger macros. Developers can refer those macro in debugger command (if applicable). 3) set breakpoint in macro 4) While executing instructions from macro expansion, debugger can monitor some variables defined out of the macro. If a variable's value is changed inside a macro, debugger will issue a message to alert the developer so as to be aware of possible unexpected side-effect.
Page 01 of 6
Method to enable macros debugging
Macros are pervasively used in programming languages such as C/C++. A macro is a name that represents a fragment of code which will substitute the name in a program appropriately (a process called macro expansion). There are two types of macros, object-like and function-like. Object-like macros do not take parameters; function-like macros do. But macros are replaced everywhere by their expansion results when preprocessing the program source file. For user-defined variables and functions, debuggers have provided fully support. But current debuggers do not provide sufficient support for developers to debug either object-like or function-like macros.
Patent 7571431 provides a tool to process macro information and display them via GUI. But developers' requirement is not only viewing the static information of various macros, but also making use of the run-time information related to the macro's expansion result. Those information is badly needed by developers to evaluate the macro's correctness while the program is debugged. For now, if a developer wants to collect run-time information about a macro's expansion results, he/she must manually substitute the macro with the statements it represents and recompile the source code and then start debugger to evaluate those statements. Doing this is inefficient and is also a tedious work. If debugger could fully support debugging macros, the developer's productivity can be highly improved and makes debugging more convenient, thus will also increase developer's satisfaction and confidence in the vendor.
The reason why debuggers could not support macros is thatcompiler will replace all macros during preprocessing phase, and macro information will not be saved as debug data in executable binary image. While debugging the program which is compiled from the source code containing macros,user can not reference macros in debug command (or set breakpoints inside macros).
This is an example from the real debugging pain point. In C/C++ programs, it usually defines macros as shortcuts to refer various functions or structure fields. For example:
In the source code, programmer usually uses macro iNode instead of writing the complete expression expanded from the macro. When debugging that code, sometime we want to display/evaluate the value iNode presents. Then we may have to page up/page down the source code view or even go to another compilation unit to get its exact expanded expressions. That obviously brings you a boring debugging experience. The reason is that iNode symbol information is not saved as debug data in executable binary image, and users have to type debug command such as "eval processInformation->attribute.nodeNumber" in debugging session.
The actual situation may be worse. Macros are not safe. They may introduce extra implicit side-effect to the program and developers often are unaware of this. Such...