*** are not supported at this language level 异常解决

IDEA 的  ****are not supported at this language level  都可以通过这个解决

比如:

for-each loops are not supported at this language level

这个异常是 设置语言等级和使用的JDK版本不符,新的JDK语法老的语言等级不支持

解决办法:

在您的模块或项目上点击F4,或者点击File->project structure ,进入project structure然后转到名为“Project”的列表中的第一个菜单项

212302_mxLs_2885163.png

project language level系统默认的是1.3 改成最新或相应版本就OK了,以后所有新建的的Module 的language level都会是改后的等级。

对于已经存在的可以在这里改:

213033_60L7_2885163.png

转载于:https://my.oschina.net/zjllovecode/blog/1533820

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Table of Contents Summary of gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Free Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Free Software Needs Free Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Contributors to gdb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 A Sample gdb Session . . . . . . . . . . . . . . . . . . . . . . 7 2 Getting In and Out of gdb . . . . . . . . . . . . . . . . 11 2.1 Invoking gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Choosing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Choosing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 What gdb Does During Startup . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Quitting gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Logging Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 11 12 13 15 16 16 16 gdb Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Command Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Running Programs Under gdb . . . . . . . . . . . . . 25 4.1 Compiling for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Starting your Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Your Program’s Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Your Program’s Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Your Program’s Working Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Your Program’s Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Debugging an Already-running Process . . . . . . . . . . . . . . . . . . . . . . 4.8 Killing the Child Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Debugging Programs with Multiple Threads . . . . . . . . . . . . . . . . . . 4.10 Debugging Programs with Multiple Processes. . . . . . . . . . . . . . . . 4.11 Setting a Bookmark to Return to Later . . . . . . . . . . . . . . . . . . . . . 4.11.1 A Non-obvious Benefit of Using Checkpoints . . . . . . . . . . . . 5 25 26 28 28 29 29 30 31 31 34 36 37 Stopping and Continuing . . . . . . . . . . . . . . . . . . 39 5.1 Breakpoints, Watchpoints, and Catchpoints . . . . . . . . . . . . . . . . . . 5.1.1 Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Setting Watchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 Setting Catchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Deleting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 40 45 47 49 ii Debugging with gdb 5.1.5 Disabling Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Break Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.7 Breakpoint Command Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.8 “Cannot insert breakpoints” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.9 “Breakpoint address adjusted...” . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Continuing and Stepping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Stopping and Starting Multi-thread Programs . . . . . . . . . . . . . . . . 6 Examining the Stack . . . . . . . . . . . . . . . . . . . . . . 61 6.1 6.2 6.3 6.4 7 Stack Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backtraces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information About a Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 62 64 65 Examining Source Files . . . . . . . . . . . . . . . . . . . 67 7.1 Printing Source Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Specifying a Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Editing Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Choosing your Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Searching Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Specifying Source Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Source and Machine Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 49 50 52 53 53 54 57 59 67 68 69 69 70 70 72 Examining Data . . . . . . . . . . . . . . . . . . . . . . . . . . 75 8.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Ambiguous Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Program Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Artificial Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Output Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Examining Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Automatic Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8 Print Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.9 Value History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.10 Convenience Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.11 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.12 Floating Point Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.13 Vector Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.14 Operating System Auxiliary Information . . . . . . . . . . . . . . . . . . . . 8.15 Memory Region Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1.1 Memory Access Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1.2 Memory Access Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1.3 Data Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.2 Memory Access Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.16 Copy Between Memory and a File . . . . . . . . . . . . . . . . . . . . . . . . . . 8.17 How to Produce a Core File from Your Program . . . . . . . . . . . . . 75 76 77 79 79 81 82 84 90 90 92 93 94 94 94 95 95 96 96 96 96 97 iii 8.18 Character Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.19 Caching Data of Remote Targets . . . . . . . . . . . . . . . . . . . . . . . . . . 100 8.20 Search Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9 C Preprocessor Macros . . . . . . . . . . . . . . . . . . 103 10 Tracepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10.1 Commands to Set Tracepoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Create and Delete Tracepoints . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Enable and Disable Tracepoints . . . . . . . . . . . . . . . . . . . . . . . 10.1.3 Tracepoint Passcounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.4 Tracepoint Action Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.5 Listing Tracepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.6 Starting and Stopping Trace Experiments . . . . . . . . . . . . . 10.2 Using the Collected Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 tfind n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 tdump. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 save-tracepoints filename . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Convenience Variables for Tracepoints . . . . . . . . . . . . . . . . . . . . . 11 Debugging Programs That Use Overlays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 11.1 11.2 11.3 11.4 12 107 107 108 108 109 110 110 111 111 113 114 114 How Overlays Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overlay Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Overlay Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overlay Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 116 118 119 Using gdb with Different Languages . . . . . 121 12.1 Switching Between Source Languages . . . . . . . . . . . . . . . . . . . . . . 12.1.1 List of Filename Extensions and Languages . . . . . . . . . . . . 12.1.2 Setting the Working Language . . . . . . . . . . . . . . . . . . . . . . . . 12.1.3 Having gdb Infer the Source Language . . . . . . . . . . . . . . . . 12.2 Displaying the Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Type and Range Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.1 An Overview of Type Checking . . . . . . . . . . . . . . . . . . . . . . . 12.3.2 An Overview of Range Checking . . . . . . . . . . . . . . . . . . . . . . 12.4 Supported Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1 C and C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.1 C and C++ Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.2 C and C++ Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.3 C++ Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.4 C and C++ Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.5 C and C++ Type and Range Checks . . . . . . . . . . . . . . 12.4.1.6 gdb and C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.7 gdb Features for C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.8 Decimal Floating Point format . . . . . . . . . . . . . . . . . . . 12.4.2 Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 121 122 122 122 123 123 124 125 125 126 127 128 129 129 129 130 131 131 iv Debugging with gdb 12.4.2.1 Method Names in Commands . . . . . . . . . . . . . . . . . . . . 12.4.2.2 The Print Command With Objective-C . . . . . . . . . . . 12.4.3 Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.3.1 Fortran Operators and Expressions . . . . . . . . . . . . . . . 12.4.3.2 Fortran Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.3.3 Special Fortran Commands . . . . . . . . . . . . . . . . . . . . . . 12.4.4 Pascal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5 Modula-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.2 Built-in Functions and Procedures . . . . . . . . . . . . . . . . 12.4.5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.4 Modula-2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.5 Modula-2 Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.6 Deviations from Standard Modula-2 . . . . . . . . . . . . . . 12.4.5.7 Modula-2 Type and Range Checks . . . . . . . . . . . . . . . 12.4.5.8 The Scope Operators :: and . . . . . . . . . . . . . . . . . . . . 12.4.5.9 gdb and Modula-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6 Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.2 Omissions from Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.3 Additions to Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.4 Stopping at the Very Beginning . . . . . . . . . . . . . . . . . . 12.4.6.5 Known Peculiarities of Ada Mode . . . . . . . . . . . . . . . . 12.5 Unsupported Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 132 132 132 133 133 133 133 133 135 136 136 138 138 138 139 139 139 139 140 141 143 143 143 13 Examining the Symbol Table . . . . . . . . . . . . 145 14 Altering Execution . . . . . . . . . . . . . . . . . . . . . 151 14.1 14.2 14.3 14.4 14.5 14.6 15 Assignment to Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continuing at a Different Address . . . . . . . . . . . . . . . . . . . . . . . . . Giving your Program a Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Returning from a Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calling Program Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patching Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 152 153 153 154 154 gdb Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 15.1 Commands to Specify Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 15.2 Debugging Information in Separate Files . . . . . . . . . . . . . . . . . . . 163 15.3 Errors Reading Symbol Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 16 Specifying a Debugging Target . . . . . . . . . . 169 16.1 Active Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 16.2 Commands for Managing Targets . . . . . . . . . . . . . . . . . . . . . . . . . . 170 16.3 Choosing Target Byte Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 v 17 Debugging Remote Programs . . . . . . . . . . . 173 17.1 Connecting to a Remote Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Sending files to a remote system . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3 Using the gdbserver Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3.1 Running gdbserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3.1.1 Attaching to a Running Program . . . . . . . . . . . . . . . . . 17.3.1.2 Multi-Process Mode for gdbserver . . . . . . . . . . . . . . . 17.3.1.3 Other Command-Line Arguments for gdbserver . . 17.3.2 Connecting to gdbserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3.3 Monitor Commands for gdbserver . . . . . . . . . . . . . . . . . . . . 17.4 Remote Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5 Implementing a Remote Stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.1 What the Stub Can Do for You . . . . . . . . . . . . . . . . . . . . . . . 17.5.2 What You Must Do for the Stub . . . . . . . . . . . . . . . . . . . . . . 17.5.3 Putting it All Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 173 175 175 175 176 176 177 177 177 178 181 182 183 184 Configuration-Specific Information . . . . . . . 185 18.1 Native. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.1 HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.2 BSD libkvm Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.3 SVR4 Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.4 Features for Debugging djgpp Programs . . . . . . . . . . . . . . 18.1.5 Features for Debugging MS Windows PE Executables . . 18.1.5.1 Support for DLLs without Debugging Symbols . . . . 18.1.5.2 DLL Name Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.5.3 Working with Minimal Symbols . . . . . . . . . . . . . . . . . . 18.1.6 Commands Specific to gnu Hurd Systems . . . . . . . . . . . . . 18.1.7 QNX Neutrino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2 Embedded Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1 Using gdb with VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1.1 Connecting to VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1.2 VxWorks Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1.3 Running Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3 Embedded Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.1 ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.2 Renesas M32R/D and M32R/SDI . . . . . . . . . . . . . . . . . . . . . 18.3.3 M68k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.4 MIPS Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.5 OpenRISC 1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.6 PowerPC Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.7 HP PA Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8 Tsqware Sparclet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.1 Setting File to Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.2 Connecting to Sparclet . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.3 Sparclet Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.4 Running and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.9 Fujitsu Sparclite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.10 Zilog Z8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 185 185 185 187 189 190 190 191 192 194 194 194 195 195 196 196 196 198 199 199 201 203 204 204 204 205 205 205 205 205 vi Debugging with gdb 18.3.11 Atmel AVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.12 CRIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.13 Renesas Super-H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4 Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.1 x86 Architecture-specific Issues . . . . . . . . . . . . . . . . . . . . . . . 18.4.2 A29K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.3 Alpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.4 MIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.5 HPPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.6 Cell Broadband Engine SPU architecture . . . . . . . . . . . . . . 18.4.7 PowerPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Controlling gdb . . . . . . . . . . . . . . . . . . . . . . . . 211 19.1 19.2 19.3 19.4 19.5 19.6 19.7 19.8 20 206 206 207 207 207 207 207 208 209 209 210 Prompt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Screen Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Current ABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optional Warnings and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . Optional Messages about Internal Happenings . . . . . . . . . . . . . . 211 211 211 213 214 214 215 217 Canned Sequences of Commands . . . . . . . . 221 20.1 20.2 20.3 20.4 User-defined Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User-defined Command Hooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commands for Controlled Output . . . . . . . . . . . . . . . . . . . . . . . . . 221 222 223 224 21 Command Interpreters . . . . . . . . . . . . . . . . . . 227 22 gdb Text User Interface . . . . . . . . . . . . . . . . . 229 22.1 22.2 22.3 22.4 22.5 23 TUI Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI Key Bindings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI Single Key Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI-specific Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 230 231 231 233 Using gdb under gnu Emacs . . . . . . . . . . . . 235 vii 24 The gdb/mi Interface . . . . . . . . . . . . . . . . . . . 237 Function and Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notation and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3 gdb/mi Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3.1 gdb/mi Input Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3.2 gdb/mi Output Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.4 gdb/mi Compatibility with CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.5 gdb/mi Development and Front Ends . . . . . . . . . . . . . . . . . . . . . 24.6 gdb/mi Output Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6.1 gdb/mi Result Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6.2 gdb/mi Stream Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6.3 gdb/mi Async Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.7 Simple Examples of gdb/mi Interaction. . . . . . . . . . . . . . . . . . . . 24.8 gdb/mi Command Description Format . . . . . . . . . . . . . . . . . . . . 24.9 gdb/mi Breakpoint Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.10 gdb/mi Program Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.11 gdb/mi Thread Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.12 gdb/mi Program Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.13 gdb/mi Stack Manipulation Commands . . . . . . . . . . . . . . . . . . 24.14 gdb/mi Variable Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.15 gdb/mi Data Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.16 gdb/mi Tracepoint Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.17 gdb/mi Symbol Query Commands . . . . . . . . . . . . . . . . . . . . . . . 24.18 gdb/mi File Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.19 gdb/mi Target Manipulation Commands . . . . . . . . . . . . . . . . . 24.20 gdb/mi File Transfer Commands . . . . . . . . . . . . . . . . . . . . . . . . . 24.21 Miscellaneous gdb/mi Commands . . . . . . . . . . . . . . . . . . . . . . . . 25 gdb Annotations . . . . . . . . . . . . . . . . . . . . . . . 293 25.1 25.2 25.3 25.4 25.5 25.6 25.7 26 237 237 237 237 238 240 240 240 240 241 241 242 243 244 251 254 255 261 265 271 277 277 280 283 287 288 What is an Annotation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Server Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annotation for gdb Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invalidation Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 294 294 294 295 295 296 Reporting Bugs in gdb . . . . . . . . . . . . . . . . . . 297 26.1 Have You Found a Bug? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 26.2 How to Report Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 viii Debugging with gdb 27 Command Line Editing . . . . . . . . . . . . . . . . . 301 27.1 Introduction to Line Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2 Readline Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.1 Readline Bare Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.2 Readline Movement Commands . . . . . . . . . . . . . . . . . . . . . . . 27.2.3 Readline Killing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.4 Readline Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.5 Searching for Commands in the History . . . . . . . . . . . . . . . 27.3 Readline Init File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.3.1 Readline Init File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.3.2 Conditional Init Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . 27.3.3 Sample Init File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4 Bindable Readline Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.1 Commands For Moving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.2 Commands For Manipulating The History . . . . . . . . . . . . . 27.4.3 Commands For Changing Text . . . . . . . . . . . . . . . . . . . . . . . 27.4.4 Killing And Yanking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.5 Specifying Numeric Arguments . . . . . . . . . . . . . . . . . . . . . . . 27.4.6 Letting Readline Type For You . . . . . . . . . . . . . . . . . . . . . . . 27.4.7 Keyboard Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.8 Some Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . 27.5 Readline vi Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 301 301 301 302 302 303 303 304 304 309 310 313 313 313 315 316 317 317 317 318 319 Using History Interactively . . . . . . . . . . . . . . 321 28.1 History Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.1.1 Event Designators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.1.2 Word Designators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.1.3 Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 321 321 322 Appendix A Formatting Documentation . . . . 325 Appendix B Installing gdb . . . . . . . . . . . . . . . . 327 B.1 B.2 B.3 B.4 B.5 Requirements for Building gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoking the gdb ‘configure’ Script . . . . . . . . . . . . . . . . . . . . . . . Compiling gdb in Another Directory . . . . . . . . . . . . . . . . . . . . . . . Specifying Names for Hosts and Targets . . . . . . . . . . . . . . . . . . . . ‘configure’ Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix C 327 327 329 330 330 Maintenance Commands . . . . . . 333 ix Appendix D gdb Remote Serial Protocol . . . 339 D.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.2 Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.3 Stop Reply Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.4 General Query Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.5 Register Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.6 Tracepoint Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.7 Host I/O Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.8 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10 File-I/O Remote Protocol Extension . . . . . . . . . . . . . . . . . . . . . . D.10.1 File-I/O Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.2 Protocol Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.3 The F Request Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.4 The F Reply Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.5 The ‘Ctrl-C’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.6 Console I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.7 List of Supported Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lseek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . unlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . stat/fstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . gettimeofday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . isatty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.8 Protocol-specific Representation of Datatypes . . . . . . . . . Integral Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointer Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memory Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . struct stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . struct timeval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.9 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mode t Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Errno Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lseek Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.10 File-I/O Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.11 Library List Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.12 Memory Map Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 340 347 348 358 358 360 362 362 363 363 363 364 364 365 365 365 366 367 367 367 368 368 369 369 370 370 370 371 371 371 372 372 372 373 373 373 373 374 374 374 375 376 x Debugging with gdb Appendix E The GDB Agent Expression Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 E.1 E.2 E.3 E.4 E.5 E.6 General Bytecode Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bytecode Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Agent Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Varying Target Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tracing on Symmetrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix F 377 379 383 384 384 386 Target Descriptions . . . . . . . . . . . 389 F.1 Retrieving Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2 Target Description Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.1 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.5 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.3 Predefined Target Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4 Standard Target Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.1 ARM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.2 MIPS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.3 M68K Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.4 PowerPC Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 390 390 390 391 391 391 392 393 393 393 394 394 Appendix G GNU GENERAL PUBLIC LICENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION . . . . . . . . . . . . . . . . . . . 396 How to Apply These Terms to Your New Programs . . . . . . . . . . . . . . . 400 Appendix H GNU Free Documentation License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 H.1 ADDENDUM: How to use this License for your documents . . 407 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 1 Summary of gdb The purpose of a debugger such as gdb is to allow you to see what is going on “inside” another program while it executes—or what another program was doing at the moment it crashed. gdb can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act: • Start your program, specifying anything that might affect its behavior. • Make your program stop on specified conditions. • Examine what has happened, when your program has stopped. • Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another. You can use gdb to debug programs written in C and C++. For more information, see Section 12.4 [Supported Languages], page 125. For more information, see Section 12.4.1 [C and C++], page 125. Support for Modula-2 is partial. [Modula-2], page 133. For information on Modula-2, see Section 12.4.5 Debugging Pascal programs which use sets, subranges, file variables, or nested functions does not currently work. gdb does not support entering expressions, printing values, or similar features using Pascal syntax. gdb can be used to debug programs written in Fortran, although it may be necessary to refer to some variables with a trailing underscore. gdb can be used to debug programs written in Objective-C, using either the Ap- ple/NeXT or the GNU Objective-C runtime. Free Software gdb is free software, protected by the gnu General Public License (GPL). The GPL gives you the freedom to copy or adapt a licensed program—but every person getting a copy also gets with it the freedom to modify that copy (which means that they must get access to the source code), and the freedom to distribute further copies. Typical software companies use copyrights to limit your freedoms; the Free Software Foundation uses the GPL to preserve these freedoms. Fundamentally, the General Public License is a license which says that you have these freedoms and that you cannot take these freedoms away from anyone else. Free Software Needs Free Documentation The biggest deficiency in the free software community today is not in the software—it is the lack of good free documentation that we can include with the free software. Many of our most important programs do not come with free reference manuals and free introductory texts. Documentation is an essential part of any software package; when an important free software package does not come with a free manual and a free tutorial, that is a major gap. We have many such gaps today. 2 Debugging with gdb Consider Perl, for instance. The tutorial manuals that people normally use are non-free. How did this come about? Because the authors of those manuals published them with restrictive terms—no copying, no modification, source files not available—which exclude them from the free software world. That wasn’t the first time this sort of thing happened, and it was far from the last. Many times we have heard a GNU user eagerly describe a manual that he is writing, his intended contribution to the community, only to learn that he had ruined everything by signing a publication contract to make it non-free. Free documentation, like free software, is a matter of freedom, not price. The problem with the non-free manual is not that publishers charge a price for printed copies—that in itself is fine. (The Free Software Foundation sells printed copies of manuals, too.) The problem is the restrictions on the use of the manual. Free manuals are available in source code form, and give you permission to copy and modify. Non-free manuals do not allow this. The criteria of freedom for a free manual are roughly the same as for free software. Redistribution (including the normal kinds of commercial redistribution) must be permitted, so that the manual can accompany every copy of the program, both on-line and on paper. Permission for modification of the technical content is crucial too. When people mod- ify the software, adding or changing features, if they are conscientious they will change the manual too—so they can provide accurate and clear documentation for the modified program. A manual that leaves you no choice but to write a new manual to document a changed version of the program is not really available to our community. Some kinds of limits on the way modification is handled are acceptable. For example, requirements to preserve the original author’s copyright notice, the distribution terms, or the list of authors, are ok. It is also no problem to require modified versions to include notice that they were modified. Even entire sections that may not be deleted or changed are acceptable, as long as they deal with nontechnical topics (like this one). These kinds of restrictions are acceptable because they don’t obstruct the community’s normal use of the manual. However, it must be possible to modify all the technical content of the manual, and then distribute the result in all the usual media, through all the usual channels. Otherwise, the restrictions obstruct the use of the manual, it is not free, and we need another manual to replace it. Please spread the word about this issue. Our community continues to lose manuals to proprietary publishing. If we spread the word that free software needs free reference manuals and free tutorials, perhaps the next person who wants to contribute by writing documentation will realize, before it is too late, that only free manuals contribute to the free software community. If you are writing documentation, please insist on publishing it under the GNU Free Documentation License or another free documentation license. Remember that this deci- sion requires your approval—you don’t have to let the publisher decide. Some commercial publishers will use a free license if you insist, but they will not propose the option; it is up to you to raise the issue and say firmly that this is what you want. If the publisher you are dealing with refuses, please try other publishers. If you’re not sure whether a proposed license is free, write to [email protected]. 3 You can encourage commercial publishers to sell more free, copylefted manuals and tutorials by buying them, and particularly by buying copies from the publishers that paid for their writing or for major improvements. Meanwhile, try to avoid buying non-free documentation at all. Check the distribution terms of a manual before you buy it, and insist that whoever seeks your business must respect your freedom. Check the history of the book, and try to reward the publishers that have paid or pay the authors to work on it. The Free Software Foundation maintains a list of free documentation published by other publishers, at http://www.fsf.org/doc/other-free-books.html. Contributors to gdb Richard Stallman was the original author of gdb, and of many other gnu programs. Many others have contributed to its development. This section attempts to credit major contrib- utors. One of the virtues of free software is that everyone is free to contribute to it; with regret, we cannot actually acknowledge everyone here. The file ‘ChangeLog’ in the gdb distribution approximates a blow-by-blow account. Changes much prior to version 2.0 are lost in the mists of time. Plea: Additions to this section are particularly welcome. If you or your friends (or enemies, to be evenhanded) have been unfairly omitted from this list, we would like to add your names! So that they may not regard their many labors as thankless, we particularly thank those who shepherded gdb through major releases: Andrew Cagney (releases 6.3, 6.2, 6.1, 6.0, 5.3, 5.2, 5.1 and 5.0); Jim Blandy (release 4.18); Jason Molenda (release 4.17); Stan Shebs (release 4.14); Fred Fish (releases 4.16, 4.15, 4.13, 4.12, 4.11, 4.10, and 4.9); Stu Grossman and John Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4); John Gilmore (releases 4.3, 4.2, 4.1, 4.0, and 3.9); Jim Kingdon (releases 3.5, 3.4, and 3.3); and Randy Smith (releases 3.2, 3.1, and 3.0). Richard Stallman, assisted at various times by Peter TerMaat, Chris Hanson, and Richard Mlynarik, handled releases through 2.8. Michael Tiemann is the author of most of the gnu C++ support in gdb, with significant additional contributions from Per Bothner and Daniel Berlin. James Clark wrote the gnu C++ demangler. Early work on C++ was by Peter TerMaat (who also did much general update work leading to release 3.0). gdb uses the BFD subroutine library to examine multiple object-file formats; BFD was a joint project of David V. Henkel-Wallace, Rich Pixley, Steve Chamberlain, and John Gilmore. David Johnson wrote the original COFF support; Pace Willison did the original support for encapsulated COFF. Brent Benson of Harris Computer Systems contributed DWARF 2 support. Adam de Boor and Bradley Davis contributed the ISI Optimum V support. Per Bothner, Noboyuki Hikichi, and Alessandro Forin contributed MIPS support. Jean-Daniel Fekete contributed Sun 386i support. Chris Hanson improved the HP9000 support. Noboyuki Hikichi and Tomoyuki Hasei contributed Sony/News OS 3 support. David Johnson con- tributed Encore Umax support. Jyrki Kuoppala contributed Altos 3068 support. Jeff Law contributed HP PA and SOM support. Keith Packard contributed NS32K support. 4 Debugging with gdb Doug Rabson contributed Acorn Risc Machine support. Bob Rusk contributed Harris Nighthawk CX-UX support. Chris Smith contributed Convex support (and Fortran de- bugging). Jonathan Stone contributed Pyramid support. Michael Tiemann contributed SPARC support. Tim Tucker contributed support for the Gould NP1 and Gould Powern- ode. Pace Willison contributed Intel 386 support. Jay Vosburgh contributed Symmetry support. Marko Mlinar contributed OpenRISC 1000 support. Andreas Schwab contributed M68K gnu/Linux support. Rich Schaefer and Peter Schauer helped with support of SunOS shared libraries. Jay Fenlason and Roland McGrath ensured that gdb and GAS agree about several machine instruction sets. Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped develop remote debugging. Intel Corporation, Wind River Systems, AMD, and ARM contributed remote debugging modules for the i960, VxWorks, A29K UDI, and RDI targets, respectively. Brian Fox is the author of the readline libraries providing command-line editing and command history. Andrew Beers of SUNY Buffalo wrote the language-switching code, the Modula-2 sup- port, and contributed the Languages chapter of this manual. Fred Fish wrote most of the support for Unix System Vr4. He also enhanced the command-completion support to cover C++ overloaded symbols. Hitachi America (now Renesas America), Ltd. H8/500, and Super-H processors. sponsored the support for H8/300, NEC sponsored the support for the v850, Vr4xxx, and Vr5xxx processors. Mitsubishi (now Renesas) sponsored the support for D10V, D30V, and M32R/D proces- sors. Toshiba sponsored the support for the TX39 Mips processor. Matsushita sponsored the support for the MN10200 and MN10300 processors. Fujitsu sponsored the support for SPARClite and FR30 processors. Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware watchpoints. Michael Snyder added support for tracepoints. Stu Grossman wrote gdbserver. Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made nearly innumerable bug fixes and cleanups throughout gdb. The following people at the Hewlett-Packard Company contributed support for the PA- RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0 (narrow mode), HP’s implementation of kernel threads, HP’s aC++ compiler, and the Text User Interface (nee Terminal User Interface): Ben Krepp, Richard Title, John Bishop, Susan Macchia, Kathy Mann, Satish Pai, India Paul, Steve Rehrauer, and Elena Zannoni. Kim Haase provided HP-specific information in this manual. DJ Delorie ported gdb to MS-DOS, for the DJGPP project. Robert Hoehne made significant contributions to the DJGPP port. Cygnus Solutions has sponsored gdb maintenance and much of its development since 1991. Cygnus engineers who have worked on gdb fulltime include Mark Alexander, Jim 5 Blandy, Per Bothner, Kevin Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler, Fernando Nasser, Geoffrey Noer, Dawn Perchik, Rich Pixley, Zdenek Radouch, Keith Seitz, Stan Shebs, David Taylor, and Elena Zannoni. In addition, Dave Brolley, Ian Carmichael, Steve Chamberlain, Nick Clifton, JT Conklin, Stan Cox, DJ Delorie, Ulrich Drepper, Frank Eigler, Doug Evans, Sean Fagan, David Henkel-Wallace, Richard Henderson, Jeff Holcomb, Jeff Law, Jim Lemke, Tom Lord, Bob Manson, Michael Meissner, Jason Merrill, Catherine Moore, Drew Moseley, Ken Raeburn, Gavin Romig-Koch, Rob Savoye, Jamie Smith, Mike Stump, Ian Taylor, Angela Thomas, Michael Tiemann, Tom Tromey, Ron Unrau, Jim Wilson, and David Zuhn have made contributions both large and small. Andrew Cagney, Fernando Nasser, and Elena Zannoni, while working for Cygnus Solu- tions, implemented the original gdb/mi interface. Jim Blandy added support for preprocessor macros, while working for Red Hat. Andrew Cagney designed gdb’s architecture vector. Many people including Andrew Cagney, Stephane Carrez, Randolph Chung, Nick Duffek, Richard Henderson, Mark Ket- tenis, Grace Sainsbury, Kei Sakamoto, Yoshinori Sato, Michael Snyder, Andreas Schwab, Jason Thorpe, Corinna Vinschen, Ulrich Weigand, and Elena Zannoni, helped with the migration of old architectures to this new framework. Andrew Cagney completely re-designed and re-implemented gdb’s unwinder framework, this consisting of a fresh new design featuring frame IDs, independent frame sniffers, and the sentinel frame. Mark Kettenis implemented the dwarf 2 unwinder, Jeff Johnston the libunwind unwinder, and Andrew Cagney the dummy, sentinel, tramp, and trad unwinders. The architecture-specific changes, each involving a complete rewrite of the architecture’s frame code, were carried out by Jim Blandy, Joel Brobecker, Kevin Buettner, Andrew Cagney, Stephane Carrez, Randolph Chung, Orjan Friberg, Richard Henderson, Daniel Jacobowitz, Jeff Johnston, Mark Kettenis, Theodore A. Roth, Kei Sakamoto, Yoshinori Sato, Michael Snyder, Corinna Vinschen, and Ulrich Weigand. Christian Zankel, Ross Morley, Bob Wilson, and Maxim Grigoriev from Tensilica, Inc. contributed support for Xtensa processors. Others who have worked on the Xtensa port of gdb in the past include Steve Tjiang, John Newlin, and Scott Foehner.
Release history (reverse chronological order) This release 1.3.7.1 Release date: December 11, 2006 Known bugs: none Fixes/features added from previous release: a) added support for multiple filters per process in VsDrvr.dll b) updated manual Previous release 1.3.5 Release date: October 11th, 2005 Known bugs: none Fixes/features added from previous release a) added VsSetWavelengthStep and VsGetWavelengthStep functions b) added VsSetWavelengthWavesConfirm() function c) fixed error-handling of VsSetWavelength() In earlier revisions, the error status light was cleared after a VsSetWavelength() call failed, so the user did not see the light turn red to alert that an error had occurred. This has been fixed in 1.35 so the error light remains lit, and an error code is returned. d) added range-check to VsDefinePalette() Previous revisions did not range-check the palette index number, and hard crashes could be produced if out-of-range values were supplied to this routine. Previous release 1.33b Release date: February 9, 2005 Known bugs: none Fixes/features changed from previous release: a) Fixed installer: programmers?guide (vsdrvr.pdf) installed when SDK is selected. Previous release 1.33a Release date: January 10th, 2005 Known bugs: i) SDK programmers?guide is not installed even if SDK is selected. Fixes/features added from previous release a) VsDrvr.dll fixed handling of COMx ports that do not support 460kb The autobaud sequence tries a variety of baud rates, some of which are not supported by RS-232 interfaces (but are supported on USB virtual COM ports). This was not handled properly, so if a call was made to VsOpen when no VariSpec was present, but a later call was made when a filter was present, the latter would fail. b) VsGui added check of which COMx ports are present on computer This program now filters its COMx list and only shows ports which actually exist; it used to show COM1 ?COM8 even if not all of these were present. c) VsGui added automatic filter detection on Configure dialog This checks all ports in turn, and reports the first detected filter. The search order is determined by the order in which the computer lists ports in the Registry. d) VsGui changed to recognize filters as present while initializing In prior revisions, VsGui would not report no filter found if a filter was present but still going through its power-up initialization. Now, a message box is posted to indicate that a filter was found, and the program checks whether initialization is complete, at 1 second intervals. When the filter is done initializing, the VsGui controls become active and report the filter information (serial number, wavelength range, etc). e) VsGui added filter status item to Configure dialog Adjacent the COMx combo box, there is now a text field that indicates filter status as 揘ot found? 揑nitializing? or 揜eady? This field is updated whenever the combo box selection is changed. Previous release 1.32 Release date: July 27th, 2004 Known bugs: COMx port described above as 1.33 fix item a) Fixes/features added from previous release a) VsGui added a sweep feature to enable cycling the filter The wavelength start, stop, and step are adjustable. Cycling can be done a fixed number of times or indefinitely. Previous release 1.30 Release date: June 23rd, 2004 Known bugs: none Fixes/features added from previous release a) New commands VsSetWaveplateAndWaves(), VsGetWaveplateAndWaves(), VsGetWaveplateLimits(), and VsGetWaveplateStages() were added for support of variable retarder models. b) New commands VsSetRetries() and VsSetLatencyMs() were added for control of serial port latency and automatic retry in case of error. c) New commands VsSetMode() and VsGetMode() were added for control of the VariSpec filter抯 triggering and sweep modes d) New command VsGetSettleMs() was added to learn optics settling time e) New commands VsIsDiagnostic() and VsIsEngagedInBeam() were added. These are reserved for CRI use and are not supported for use by end users. f) The command syntax and functionality of the VsSendCommand() function was changed - see description of this command for details g) The VsGui program was modified to add sweep function, and the associated files were added to the file manifest. The new functions are assigned higher ordinal numbers than the earlier commands, so the ordinal numbers assigned to routines in the earlier VsDrvr routines are preserved. This means one may use the new VsDrvr.dll file with applications that were developed and linked with the earlier release, without any need to recompile or relink the application. Of course, to use the new functions one must link the application code with the new .lib file containing these functions. Previous release: 1.20 Release date December 3rd, 2003 Known bugs: a) there is a conflict when one uses the implicit palette to set wavelengths, and also defines palette states explicitly using the VsDefinePalette() function. When the explicitly set palette state overwrites a palette state implicitly associated with a certain wavelength, that wavelength will not be accurately set when one issues the VsSetWavelength() command. This is fixed in release 1.30 Fixes/features added from previous release a) fixes bug with implicit palette in September 8 release b) incorporates implicit retry for command send/reply if error in transmission c) recognizes filters with serial numbers > 60000 (normally VariLC numbers) d) supports binary transfer of >127 bytes Previous release 1.11 Release date September 8, 2003 Known bugs a) implicit palette can fail to create palette entry, causing tuning error b) VsSendBinary() fails if 128 chars or more sent (signed char error) Fixes/features added from previous release a) included VsIsPresent() function omitted from function list of 1.10 release Previous release 1.10 Release date: August 28th, 2003 Known bugs: a) VsIsPresent function not included ?generates 搖nresolved external?at link-time Fixes/features added from previous release: b) added command VsEnableImplicitPalette() to code and documentation added command VsConnect() to code and documentation added command VsClose() to code and documentation added local variable to avoid unnecessary querying of diagnostic status documented that command VsConnect() will not be supported in future documented that command VsDisconnect() will not be supported in future documented that command VsIsConnected() will not be supported in future changed to Windows Installer from previous ZIP file added table summary of commands to this manual Previous release 1.00 Release date: November 5th, 2002 Known bugs: a) none Fixes/features added from previous release b) n/a ?initial releaseDescription This package provides a set of functions to control the VariSpec filter, which may be called from C or C++ programs. It incorporates all aspects of the filter communication, including low-level serial routines. With these routines, one can address the filter as a virtual object, with little need for detailed understanding of its behavior. This simplifies the programming task for those who want to integrate the VariSpec into larger software packages. File manifest All files are contained in a single installer file which includes the following: vsdrvr.h declaration file vsdrvr.lib library stub file vsdrvr.dll run-time library vsdrvr_r1p30.pdf (this file) release notes and programmer抯 guide {sample program using VsDrvr package} registryAccess.cpp registryAccess.h resource.h stdafx.h VsConfigDlg.cpp VsConfigfDlg.h VsGui.cpp VsGui.h VsGui.mak VsGui.rc VsGuiDlg.cpp VsGuiDlg.h VsSweep.cpp VsSweep.h Development cycle In order to use the DLL, one should take the following steps: a) Add #include 搗sdrvr.h?statements to all files that access the VariSpec software b) Add vsdrvr.lib to the list of modules searched by the linker c) Place a copy of vsdrvr.dll in either the folder that includes the executable code for the program being developed; or, preferably, in the windows system folder. Failures in step a) will lead to compiler errors; in step b) to linker errors; in step c) to a run-time error message that 揳 required .DLL file, vsdrvr.dll, was not found? VariSpec filter configuration The VariSpec filter communicates via ASCII commands sent over an RS-232 interface or USB. The RS232 can operate at 9600 or 19,200 baud, while the USB appears as a virtual COMx device. While it appears to be present at either 9600 baud or 115.2 kbaud , the actual data transmission occurs at 12 MBaud over the USB. Each command is terminated with an end-of-line terminator which can be either a carriage-return <c/r> or line feed <l/f>. For RS-232 models, the baud rate and terminator character are selected using DIP switches inside the VariSpec electronics module. Default settings are 9600 baud, and the <c/r> character (denoted 慭r?in the C language). For USB devices, the terminator is always <c/r>. For latest information, or to determine how to alter the settings from the factory defaults, consult the VariSpec manual. Timing and latency The VariSpec filter takes a finite time to process commands, which adds an additional delay to that imposed by simple communication delays. In general, the time to process a given command is short except for the following operations: ?filter initialization ?wavelength selection ?palette definition The first of these is quite lengthy (30 seconds or more) because it involves measurements and exercising of the liquid crystal optics. The latter two are much faster but still can take a significant amount of time (up to 300 ms) on the older RS-232 electronics due to the computations involved. On the newer, USB electronics, the latter two functions are completed in less than 5 ms. For this reason, the functions that handle these actions offer the option of waiting until the action is complete before returning (so-called synchronous operation); although they can be called in an asynchronous mode where the function returns as soon as all commands have been sent to the VariSpec, without waiting for them to run to completion. Another option is to use implicit palette tables. If this is enabled, by calling the VsEnableImplicitPalette() function, the driver will define the settings for a given wavelength once, then saves the results within the VariSpec for faster access next time that wavelength is used. Subsequent access times are essentially instantaneous, until either all of the 128 palette states are in use, or the palette is cleared via the VsClearPalette() command. The VsIsReady() function can be used to determine whether a filter is done processing all commands. Ideally, one should check VsIsReady() using a timer or the like to wait efficiently, so that the host PC is free to do other tasks while waiting for the VariSpec. The VariSpec always processes each command to completion before starting on the next command, and it has a 256 byte input buffer, so there is no problem issuing several commands at once; they will all be executed, and in the order given. This also indicates another way to coordinate one抯 program with the VariSpec filter: one can issue any of the VsGetxxx() functions, which query the filter. Since these do not return until the filter has responded, one may be sure that there are no pending commands when the VsGetxxx() function completes. The VsDrvr package provides for automatic re-try of commands up to 3 times, in the event that communications are garbled, and will wait up to 2 seconds for completion of serial commands. The number of retries can be set from 0 to 10, and the latency adjusted, if desired. However, there should be no need to do so. The hardware and software have been tested and observed to execute several million commands without a single communications error, so in practice the need for the retry protocol is very slight. Communication speed is not improved by reducing the latency, since commands proceed when all characters are received, and the latency time to time-out is only relevent when there is a communications lapse ?and as noted, these are very unlikely so the performance burden of retries should not be a practical consideration. Multiple Filters and Multiple Processes These routines only permit one VariSpec per process, and one process per VariSpec. So, these routines cannot control multiple filters at once from a single process; nor can several active processes seek to control the same filter at the same time. The VsDrvr package anticipates a future upgrade to enable control of multiple filters per process, so it makes use of an integer handle to identify which VariSpec is being controlled, even though (for now) only a single filter can be active. This handle is checked, and the correct handle must be used in all calls. Program flow and sequence Typical programs should use the following API calls (all applications, upon initiating link to the filter) ?call VsOpen() to establish communications link (required) ?call VsIsPresent() to confirm a filter is actually present ?call VsIsReady() in case filter is still doing power-up sequence <wait until no longer busy> ?call VsGetFilterIdentity() to learn wavelength limits and serial number if needed (if setting wavelengths via implicit palettes; recommended especially with older filters) ?call VsEnableImplicitPalettes() ? (to set wavelengths, either directly or via implicit palettes) ?call VsSetWavelength() and VsGetWavelength() to select and retrieve tuning (if setting wavelengths by means of palettes, and managing palettes explicity) ?call VsDefinePaletteEntry() and VsClearPalette() to define palette entries ?call VsSetPalette() and VsGetPalette() to select and retrieve palette state (all applications, when done with the filter) ?call VsClose() to release the communications link (required) Sample program Source code for a sample program, VsGui, is provided, which illustrates how to control a VariSpec filter using the VsDrvr package. All filter control code lives in the VsGuiDlg.cpp module, specifically in the Connect(), RequestToSetWavelength(), and VsWriteTimerProc() functions. The latter two use a system timer to decouple the GUI from the actual filter control, for more responsive feedback to the user. Such an approach is unnecessary if palettes are used, which is preferable when one wishes the best real-time performance. See the VariSpec manual for further information. Auxiliary commands Certain commands are normally only used at the factory when filters are being built and configured, or in specialized configurations. These appear after the normal command set in the listing below. Obsolescent commands The VsConnect(), VsIsConnected(), and VsDisconnect() functions are obsolescent. They are supported in this release, but will not necessarily exist in releases after 1.3x. As they are obsolescent, they are not recommended for new code. These function calls are not documented further in this manual.Summary of commands Normal Commands VsClearError(vsHnd) VsClearPalette(vsHnd) VsClearPendingCommands(vsHnd) VsClose(vsHnd) VsDefinePalette(vsHnd, palEntry, wl) VsEnableImplicitPalette(vsHnd, isEnabled) VsGetError(vsHnd, *pErr) VsGetFilterIdentity(vsHnd, *pVer, *pSerno, *pminWl, *pmaxWl) VsGetMode(vsHnd, int *pMode) VsGetPalette(vsHnd, *ppalEntryNo) VsGetSettleMs(vsHnd, *psettleMs) VsGetTemperature(vsHnd, *pTemperature) VsGetWavelength(vsHnd, *pwl) VsGetWavelengthAndWaves(vsHnd, double *pWl, double *pwaves) VsGetWaveplateLimits(vsHnd, double *pminWaves, double *pmaxWaves) VsGetWaveplateStages(vsHnd, int *pnStages) VsIsPresent(vsHnd) VsIsReady(vsHnd) VsOpen(*pvsHnd, portName, *pErrorCode) VsSetLatencyMs(vsHnd, nLatencyMs) VsSetMode(vsHnd, mode) VsSetPalette(vsHnd, palEntry) VsSetRetries(vsHnd, nRetries) VsSetWavelength(vsHnd, wl, confirm) VsSetWavelengthAndWaves(vsHnd, wl, waveplateVector) Auxiliary commands VsGetAllDrive(vsHnd, *pStages, drive[]) VsGetNstages(vsHnd, *pStages) VsGetPendingReply(vsHnd, reply, nChars, *pQuit, firstMs, subsequentMs) VsGetReply(vsHnd, reply, nChars, waitMs) VsIsDiagnostic(vsHnd) VsIsEngagedInBeam(vsHnd) VsSendBinary(vsHnd, bin[], nChars, clearEcho) VsSendCommand(vsHnd, cmd, sendEolChar) VsSetStageDrive(vsHnd, stage, drive) VsThermistorCounts(vsHnd, *pCounts) Alphabetical list of function calls Syntax Throughout this manual, the following conventions are used: VSDRVR_API Int32 VsOpen( VS_HANDLE *vsHnd, LPCSTR port, Int32 *pErrorCode ) Bold text is used for function names Italics indicate variables whose names (or values) are supplied by the user in their code Name-mangling The declaration file vsdrvr.h includes statements that render the API names accurately in a C++ environment, i.e. free of the name-mangling decoration suffix that is normally added by C++ compilers. Thus the functions can be called freely from either C or C++ programs, using the names exactly as shown in this manual or in the VsDrvr.h file. Call and argument declarations The call protocol type, VSDRVR_API, is declared in vsdrvr.h, as are the types Int32 and VS_HANDLE. Errors All functions return an Int32 status value, which is TRUE if the routine completed successfully and FALSE if there was an error. If there is an error in the VsOpen() function, the error is returned in *pErrorCode. If there is an error in communicating with a filter after a successful VsOpen(), one should use the VsGetError() function to obtain the specific error code involved. This function returns VSD_ERR_NOERROR if there is no error pending. Main and auxiliary functions The next section provides a description of the main functions, in alphabetic order; followed by the auxiliary functions, also in alphabetical order. In normal use, one will probably have no need for the auxiliary functions, but this list is provided for completeness. VSDRVR_API Int32 VsClearError( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Purpose: this function clears any pending error on the VariSpec. This resets the error LED on the filter, and sets the pending error to VS_ERR_NOERROR. Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsClearPalette( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Function: clears all elements of the current filter palette and renders the current palette element undefined. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsClearPendingCommands( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Function: clears all pending commands including any presently in-process Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsClose( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen(). May also be NULL, in which case all VariSpec filters are disconnected. Function: Disconnects the filter. Returns: TRUE if successful, FALSE otherwise Notes: No other functions will work until VsOpen() is called to re-establish communications with the filter. VSDRVR_API Int32 VsDefinePalette( VS_HANDLE vsHnd, Int32 palEntry, double wl) Arguments: vsHnd handle value returned by VsOpen() palEntry palette entry to be defined, in the range [0, 127] wl wavelength associated with this palette entry Function: creates a palette entry for the entry and wavelength specified. This palette entry can then be accessed using VsSetPalette() and VsGetPalette() functions. Returns: TRUE if successful, FALSE otherwise Notes: palettes provide a fast way to define filter settings for wavelengths that are to be repeatedly accessed. The calculations are performed once, at the time the palette element is defined, and the results are saved in a palette table to tune to that wavelength without repeating the underlying calculations. And, one may cycle through the palette table, once defined, by means of TTL a trigger signal to the filter electronics. For more information about using palettes, consult the VariSpec user抯 manual. VSDRVR_API Int32 VsEnableImplicitPalette( VS_HANDLE vsHnd, BOOL imlEnabled) Arguments: vsHnd handle value returned by VsOpen() implEnabled selects whether to use implicit palette definition Function: enables or disables implicit palette generation when wavelengths are defined using the VsSetWavelength function. If enabled, a new palette entry is created whenever a new wavelength is accessed, and the VsSetWavelength function will use this palette entry whenever that wavelength is accessed again, until the palette is cleared. The result is improved tuning speed; however, it means that the palette contents are altered dynamically, which can be a problem if one relies upon the palette contents remaining fixed. Clearing the palette with VsClearPalette() will clear all implicit palette entries as well as explicitly defined palette entries. This is useful if one knows that wavelengths used previously will not be used again, or that a new set of wavelengths is about to be defined and one wishes to make sure there is sufficient room in the palette. Returns: TRUE if successful, FALSE otherwise Notes: By default, the implicit palette is enabled for VariSpec filters that have RS-232 interface, and is disabled for newer VariSpec filters that have the USB interface. This is because the newer filters perform the filter tuning calculations fast enough that no performance improvement is obtained by using the implicit palette to set wavelength. For more information about using palettes, consult the VariSpec user抯 manual. VSDRVR_API Int32 VsGetError( VS_HANDLE vsHnd, Int32 *pErr) Arguments: vsHnd handle value returned by VsOpen() pErr pointer to the int that will receive the most recent error code Purpose: this function clears any pending error on the VariSpec. This resets the error LED on the filter, and sets the pending error to VS_ERR_NOERROR. Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsGetFilterIdentity( VS_HANDLE vsHnd, Int32 *pVer, Int32 *pSerno, double *pminWl, double *pmaxWl ) Arguments: vsHnd handle value returned by VsOpen() pVer pointer to variable that receives the filter firmware version pSerno pointer to variable that receives the filter serial number pminWl pointer to variable that receives the filter抯 minimum wavelength pmaxWl pointer to variable that receives the filter抯 maximum wavelength Purpose: this function reads the filter抯 information using the VariSpec 慥?command, and puts it to the call variables. Any one of the pointers may be NULL, in which case that piece of information is not returned. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsGetMode( VS_HANDLE vsHnd, Int32 *pMode ) Arguments: vsHnd handle value returned by VsOpen() pMode pointer to variable that receives the filter mode Purpose: this function enables one to read the filter抯 present mode. The mode describes how the filter responds to hardware triggers, and is described in the filter manual. If the pointer *pMode is NULL, no information is returned. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsGetPalette( VS_HANDLE vsHnd, Int32 *ppalEntry ) Arguments: vsHnd handle value returned by VsOpen() ppalEntry pointer to int that receives the 0-based palette entry number. This pointer may not be NULL. Purpose: this function determines what palette entry is currently active and returns it to *ppalEntry. If the present palette entry is undefined, it sets *ppalEntry to ? and returns a successful status code. Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsGetSettleMs( VS_HANDLE vsHnd, Int32 *pSettleMs ) Arguments: vsHnd handle value returned by VsOpen() pSettleMs pointer to variable that receives the filter settling time Purpose: this function returns the filter抯 settling time, in milliseconds. This is useful for establishing overall system timing. The settling time is defined as beginning at the moment that the electronics have processed the request to change wavelength, as determined by VsIsReady() or equivalent. At that moment, the new set of drive signals are applied to the optics, and the optics will settle in *psettleMs milliseconds. The settling time is defined as a 95% settling time, meaning the filter has settled to 95% of its ultimate transmission value at the new wavelength being tuned to. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsGetTemperature( VS_HANDLE vsHnd, double *pTemperature ) Arguments: vsHnd handle value returned by VsOpen() pTemperature pointer to double that will receive the filter temperature, in C This pointer may not be NULL Purpose: this function determines the filter temperature using the VariSpec 慪?command, and puts the result to *pTemperature. Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsGetWavelength( VS_HANDLE vsHnd, double *pwl ) Arguments: vsHnd handle value returned by VsOpen() pwl pointer to double that will receive the filter wavelength, in nm This pointer may not be NULL Purpose: this function determines the current filter wavelength and returns it to *pwl. If the present wavelength is undefined, it sets *pwl to ? and returns a successful status code. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsGetWavelengthAndWaves( VS_HANDLE vsHnd, double *pwl, double *pwaves ) Arguments: vsHnd handle value returned by VsOpen() pwl pointer to double that will receive the filter wavelength, in nm. This pointer may not be NULL pwaves pointer to double array that will receive one or more waveplate settings. The actual number of settings may be determined by VsGetWaveplateStages(). Purpose: this function determines the current filter wavelength and returns it to *pwl. If the present wavelength is undefined, it sets *pwl to ? and returns a successful status code. If the present wavelength is defined, it also returns the waves of retardance at each of the polarization analysis waveplates in the optics, in the pwaves[] array. Returns: TRUE if successful, FALSE otherwise Notes: See the description of the VsGetWaveplateStages() command for more detail on what stages are considered waveplates. VSDRVR_API Int32 VsGetWaveplateLimits( VS_HANDLE vsHnd, double *pminWaves, double *pmaxWaves ) Arguments: vsHnd handle value returned by VsOpen() pminWaves pointer to double array that will receive the minimum retardances possible at each of the waveplate stages in the filter optics. pmaxWaves pointer to double array that will receive the maximum retardances possible at each of the waveplate stages in the filter optics Purpose: this function determines the range of retardances that are possible at each waveplate stage, in waves, at the present wavelength setting. Note that the retardance range is itself a function of wavelength, so the results will vary as the wavelength is changed. Returns: TRUE if successful, FALSE otherwise Notes: See the description of the VsGetWaveplateStages command for more detail on what stages are considered waveplates. VSDRVR_API Int32 VsGetWaveplateStages( VS_HANDLE vsHnd, Int32 *pnwpStages ) Arguments: vsHnd handle value returned by VsOpen() pnwpStages pointer to Int32 that will receive the number of waveplate stages in the filter optics. This pointer may not be NULL Purpose: this function determines how many polarization analysis stages are present in the optics and returns this number. Note that although all VariSpec filters operate by means of variable retarder element, optical stages that perform wavelength tuning rather than polarization analysis are not treated as waveplate stages. For example, most VariSpec filters do not include any polarization analysis stages and thus report no waveplates. VsGetWaveplateStages will return a value of 2 for conventional PolScope optics. In contrast, VsGetNstages() reports the total number of stages in a filter, including stages that perform polarization analysis and stages that perform wavelength tuning. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsIsPresent( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Function: determines whether a filter is actually present and responding. This is done using the status-check character ??as described in the VariSpec manual. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsIsReady( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Function: determines whether the filter is done processing all commands, and is ready to receive new commands. Returns: TRUE if successful, FALSE otherwise Notes: this is useful when sending commands such as VsSetWavelength(), VsInitialize(), VsExercise(), and VsDefinePaletteEntry() in asynchronous mode. These commands take a prolonged time, and running them synchronously ties up the processor waiting. Alternatively, one can create a loop that uses CreateWaitableTimer(), SetWaitableTimer(), and WaitForSingleObject() to call VsIsReady() at intervals, checking whether the filter is ready. This approach, though more work for the programmer, leaves most of the processor capacity free for other tasks such as GUI update and the like. VSDRVR_API Int32 VsOpen (VS_HANDLE *pvsHnd, LPCSTR port, Int32 *pErrorCode ) Arguments: pvsHnd pointer to handle. This pointer may not be NULL. port port name, such as 揅OM1? pErrorCode pointer to Int32 to receive an error code if VsOpen() fails Purpose: establishes a connection to the VariSpec using the port specified, and automatically determines the baud rate and end-of-line character for subsequent communications. It also retrieves the filter抯 serial number and wavelength range, to confirm that it is a VariSpec and not some other similar device. However, these are retrieved purely as an integrity check, and the values are not returned to the calling application. See VsGetFilterInfo() to access this information. If the device responds as a VariSpec does when it is not ready (i.e. still initializing), VsOpen() fails and returns the error code VSD_ERR_BUSY. However, one may not be sure that the device is a VariSpec until VsOpen() completes successfully The error codes returned by this function are listed in VsDrvr.h. When VsOpen() runs successfully, *pErrorCode is set to VSD_ERR_NOERROR. The handle associated with this filter is set by VsOpen() to a nonzero handle value if successful, or to NULL if no connection is established. The port may refer to COM1 through COM8. Return: TRUE if successful, FALSE otherwise Notes: Until this function is called, none of the other functions will work. VSDRVR_API Int32 VsSetLatency( VS_HANDLE vsHnd, Int32 latencyMs ) Arguments: vsHnd handle value returned by VsOpen() latencyMs the serial port latency, in ms, in the range [1, 5000] Purpose: this function sets the latency time for USB or RS-232 commands to the value given by latencyMs. Commands that do not conclude in this time are considered to have timed-out. Returns: TRUE if successful, FALSE otherwise Notes: increasing the latency time does not increase the time for commands to complete, nor does it insert any delays in normal processing. It merely defines the window for maximum transmission time, beyond which time an error is reported. VSDRVR_API Int32 VsSetPalette( VS_HANDLE vsHnd, Int32 palEntry ) Arguments: vsHnd handle value returned by VsOpen() palEntry the palette entry to be set, in the range [0, 127] Purpose: this function sets the filter to the palette entry specified by palEntry Returns: TRUE if successful, FALSE otherwise Notes: palettes are a good way to control the filter in applications where it will be cycled repeatedly to various, fixed wavelength settings. Palettes calculate the filter settings once, and save the results for rapid access later, rather than calculating them each time, as occurs when one sets the wavelength directly with VsSetWavelength(). See the VariSpec manual for more information on palettes.VSDRVR_API Int32 VsSetRetries( VS_HANDLE vsHnd, Int32 nRetries ) Arguments: vsHnd handle value returned by VsOpen() nRetries the number serial communications retries, in the range [0, 10] Purpose: The VsDrvr software automatically detects errors in communication and re-sends if an error is detected. This function sets the number of times to retry sending any single command, before reporting a communications failure. The default is 3, which should be adequate, and one should rarely need to change this, if ever. The primary purpose of this function is to enable setting the number of retries to zero, to force single-error events to cause detectable errors (as they would normally be fixed automatically via the retry mechanism) Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsSetWavelength( VS_HANDLE vsHnd, double wl, BOOL confirm ) Arguments: vsHnd handle value returned by VsOpen() wl wavelength to tune to, in nm confirm logical flag, indicating whether to confirm actual wavelength value Purpose: this function sets the filter wavelength to the value in wl. If confirm is TRUE, it waits for the filter to complete the command, and then reads back the actual wavelength to confirm it was implemented successfully. Note that the only time there can be a disparity is when the wavelength requested by wl lies outside the legal range for that filter, or if the wavelength is specified to a finer resolution than the filter recognizes (normally, 0.01 nm). Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsGetAllDrive( VS_HANDLE vsHnd, Int32 *pStages, Int32 drive[] ) Arguments: vsHnd handle value returned by VsOpen() pStages pointer to int that will receive the number of stages in the filter drive[] int array to receive the filter drive levels. Purpose: this function reports the number of filter stages in *pStages. If this argument is NULL, it is ignored. The function returns the actual drive level at each stage, in counts, in drive[] , which must not be NULL. Returns: TRUE if successful, FALSE otherwise Notes: The array drive[] must be large enough to receive all the drive levels ?if the exact number of stages is not known, call VsGetNstages() first, or allocate enough array elements (12) to accommodate the largest filter design.VSDRVR_API Int32 VsGetNstages( VS_HANDLE vsHnd, Int32 *pStages ) Arguments: vsHnd handle value returned by VsOpen() pStages pointer to int that will receive the number of stages in the filter Purpose: this function determines the number of optical stages in the filter and returns it in *pStages, which may not be NULL. Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsGetPendingReply( VS_HANDLE vsHnd, LPSTR reply, Int32 nChars, Int32 *pQuit, Int32 firstMs, Int32 subsequentMs ) Arguments: vsHnd handle value returned by VsOpen() reply pointer to buffer that is to receive the reply nChars number of characters to receive pQuit pointer to flag to control this function ?see Notes below firstMs maximum time to wait, in ms, for first character of reply subsequentMs maximum time to wait, in ms, for each subsequent character Purpose: this function is used to exploit some of the less-common aspects of the filter, and it is likely that most programs will require its use. It receives a reply from the filter that may not arrive for a long time. The routine waits up to firstMs for the first character to arrive. Subsequent characters must arrive within subsequentMs of one another. Typically, this routine is called with a high value for firstMs and a lower value for subsequentMs. Returns: TRUE if successful, FALSE otherwise Notes: pQuit can be used to cancel this function while it is waiting for the reply, if that is desired, such as to respond to a user cancellation request. To use this feature, pQuit must be non-NULL and *pQuit must be FALSE at the time VsGetPendingReply() is called. VsGetPendingReply() checks this address periodically, and if it discovers that *pQuit is TRUE, it will cancel and return immediately.VSDRVR_API Int32 VsGetReply( VS_HANDLE vsHnd, LPSTR reply, Int32 nChars, Int32 waitMs ) Arguments: vsHnd handle value returned by VsOpen() reply pointer to buffer that will receive the filter reply nChars the number of characters sought waitMs the maximum time, in ms, to wait for the reply Purpose: this function is used to exploit those filter commands that are not directly provided by other functions, and most programmers will not need to use it. If the reply is not received in the time indicated by waitMs, or if less than nChars are received, the function returns with an unsuccessful status code. Returns: TRUE if successful, FALSE otherwise Notes: noneVSDRVR_API Int32 VsIsDiagnostic( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Function: determines whether the filter is in the diagnostic mode that is used at the factory for setup and calibration. This command is reserved for CRI use only. Returns: TRUE if diagnostic, FALSE otherwise. VSDRVR_API Int32 VsIsEngagedInBeam( VS_HANDLE vsHnd ) Arguments: vsHnd handle value returned by VsOpen() Function: determines whether the filter is engaged in the beam, when configured into certain CRI systems. This function is reserved for CRI use only Returns: TRUE if engaged in the beam, FALSE otherwise VSDRVR_API Int32 VsSendBinary( VS_HANDLE vsHnd, char *bin, Int32 nChars, BOOL clearEcho ) Arguments: vsHnd handle value returned by VsOpen() bin pointer a buffer that contains binary data to be sent to the filter nChars the number of binary characters to be sent clearEcho flag indicating whether to clear echo characters from the queue Purpose: this routine sends binary blocks of data to the filter. This is only necessary when programming calibration data to the filter, and it is not anticipated that this function will be necessary in any normal use. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsSendCommand( VS_HANDLE vsHnd, LPCSTR cmd, BOOL sendEolChar) Arguments: vsHnd handle value returned by VsOpen() cmd pointer to the command to be sent to the filter sendEolChar flag indicating whether to append the end-of-line character or not Purpose: this function sends the command in cmd to the filter, and appends an end-of-line terminator (or not) based on sendEolChar. It automatically retrieves and discards the character echo of this command by the VariSpec. It does not automatically retrieve the reply, if any, from the VariSpec. Returns: TRUE if successful, FALSE otherwise Notes: The parameter sendEolChar should normally be true in all cases, unless one is sending individual character commands such as the ??or 慇?commands described in the VariSpec user抯 manual.VSDRVR_API Int32 VsSetStageDrive( VS_HANDLE vsHnd, Int32 stage, Int32 drive ) Arguments: vsHnd handle value returned by VsOpen() stage stage number whose drive level is to be adjusted drive drive level, in counts, for that stage Purpose: this function provides a way to manually adjust the drive levels at each of the filter抯 optical stages. It is normally used only during manufacture, and is not a function that most software programs will have any reason to use. Returns: TRUE if successful, FALSE otherwise Notes: none VSDRVR_API Int32 VsThermistorCounts( VS_HANDLE vsHnd, Int32 *pCounts ) Arguments: vsHnd handle value returned by VsOpen() pCounts pointer to int that will receive the thermistor signal, in counts Purpose: this function provides a way to determine the signal level, in counts, at the thermistor. It is normally used only during manufacture, and is not a function that most software programs will have any reason to use. Returns: TRUE if successful, FALSE otherwise Notes: none
Paperback: 304 pages Publisher: Newnes; 4 edition (April 19, 2005) Language: English ISBN-10: 0750665750 ISBN-13: 978-0750665759 Unlike most engineering maths texts, this book does not assume a firm grasp of GCSE maths, and unlike low-level general maths texts, the content is tailored specifically for the needs of engineers. The result is a unique book written for engineering students, which takes a starting point below GCSE level. Basic Engineering Mathematics is therefore ideal for students of a wide range of abilities, and especially for those who find the theoretical side of mathematics difficult. All students taking vocational engineering courses who require fundamental knowledge of mathematics for engineering and do not have prior knowledge beyond basic school mathematics, will find this book essential reading. The content has been designed primarily to meet the needs of students studying Level 2 courses, including GCSE Engineering and Intermediate GNVQ, and is matched to BTEC First specifications. However Level 3 students will also find this text to be a useful resource for getting to grips with the essential mathematics concepts needed for their study, as the compulsory topics required in BTEC National and AVCE / A Level courses are also addressed. The fourth edition incorporates new material on adding waveforms, graphs with logarithmic scales, and inequalities - key topics needed for GCSE and Level 2 study. John Bird's approach is based on numerous worked examples, supported by 600 worked problems, followed by 1050 further problems within exercises included throughout the text. In addition, 15 Assignments are included at regular intervals. Ideal for use as tests or homework, full solutions to the Assignments are supplied in the accompanying Instructor's Manual, available as a free download for lecturers from http://textbooks.elsevier.com. * Unique in introducing fundamental mathematics from an engineering perspective, with a starting point below GCSE level * Fully matched to BTEC First and BTEC National core unit specifications * Free instructor's manual available to download - contains worked solutions and suggested mark scheme

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值