Changes between Version 22 and Version 23 of Tools/Gdb Server
- Timestamp:
- Dec 7, 2009, 11:14:35 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Tools/Gdb Server
v22 v23 1 1 2 = GDB Server for So clib =2 = GDB Server for SoCLib = 3 3 4 The !GdbServer tool is a software debugger for !SoC lib.4 The !GdbServer tool is a software debugger for !SoCLib. 5 5 6 6 == Overview == 7 7 8 The !GdbServer is able to manage all processors in a soclib platform. It listens for TCP connection from [http://www.gnu.org/software/gdb/ Gnu GDB] clients. Once connected, clients can be used to freeze, run, step every processor in the platform, add breakpoints, catch exceptions and dump registers and memory content.8 The !GdbServer is able to manage all processors in a !SoCLib platform. It listens for TCP connection from [http://www.gnu.org/software/gdb/ Gnu GDB] clients. Once connected, clients can be used to freeze, run, step every processor in the platform, add breakpoints, catch exceptions and dump registers and memory content. 9 9 10 10 == Implementation == 11 11 12 The !GdbServer contains no processor specific code and can be used to manage any Soclib processor model using the generic Iss interface. It is implemented as an Iss wrapper class. When the !GdbServer is in use, it intercepts all events between the processor Iss model and the Soclib platform. This enables the !GdbServer to access platform ressources as viewed from the processor without modifing platform components or processor model source code. The !GdbServer is able to freeze the wrapped processor model while the platform is still running.12 The !GdbServer contains no processor specific code and can be used to manage any !SoCLib processor model using the generic Iss interface. It is implemented as an Iss wrapper class. When the !GdbServer is in use, it intercepts all events between the processor Iss model and the !SoCLib platform. This enables the !GdbServer to access platform resources as viewed from the processor without modifying platform components or processor model source code. The !GdbServer is able to freeze the wrapped processor model while the platform is still running. 13 13 14 In order to simp fify the debug in a multi-processor context, all processors wrapped in a !GdbServer will be frozen when a breakpoint is detected in one single processor.14 In order to simplify the debug in a multi-processor context, all processors wrapped in a !GdbServer will be frozen when a breakpoint is detected in one single processor. 15 15 16 16 == Usage == … … 137 137 The gdb client offers a easy way to send server specific data though the `monitor` command. Our GdbServer takes advantages of the `monitor` command to provide useful advanced features: 138 138 139 * The !GdbServer may be instructed to dump every inter-function branch to produ de a calltrace on stderr. The {{{set_loader}}} function must be used on Gdb iss to enable this feature. This can be enabled globally by adding the `C` flag to the `SOCLIB_GDB` environment variable; or on a per processor basis using the calltrace command:139 * The !GdbServer may be instructed to dump every inter-function branch to produce a calltrace on stderr. The {{{set_loader}}} function must be used on Gdb iss to enable this feature. This can be enabled globally by adding the `C` flag to the `SOCLIB_GDB` environment variable (or the `Z` flag for dumping only call to function's entrypoint); or on a per processor basis using the calltrace command: 140 140 {{{ 141 141 (gdb) monitor calltrace 0 # disable for all processors … … 153 153 (gdb) monitor except 0 2 # disable for thread 2 (processor 1) 154 154 }}} 155 Exception catching is enabled by default but can be disabled global y by adding the `X` flag to the the `SOCLIB_GDB` environment variable.155 Exception catching is enabled by default but can be disabled globally by adding the `X` flag to the the `SOCLIB_GDB` environment variable. 156 156 157 * An alternative way to set hardware watch point range is provided to bypass the sometime annoying gdb client watch point feature. It can be used to modif iy directly the read and write watching intervals. The following commands set a 4 bytes (default is cpu register width) read/write watch interval at 0x12345678 and then excludes read watching for 32 bytes range at 0x12345000. These watch points will be unknown to the gdb client and will be lost when the simulation terminates.157 * An alternative way to set hardware watch point range is provided to bypass the sometime annoying gdb client watch point feature. It can be used to modify directly the read and write watching intervals. The following commands set a 4 bytes (default is cpu register width) read/write watch interval at 0x12345678 and then excludes read watching for 32 bytes range at 0x12345000. These watch points will be unknown to the gdb client and will be lost when the simulation terminates. 158 158 {{{ 159 159 (gdb) monitor watch rw 0x12345678 … … 166 166 export SOCLIB_GDB_WATCH=0x12340000r:0x45870000rw # read watch [0x12340000, 0x12340003], rw watch [0x45870000, 0x45870003] 167 167 }}} 168 The `W` flag can be added to the the `SOCLIB_GDB` variable to just rep port watchpoint hit on stderr and avoid stoping the simulation to be less intrusive.168 The `W` flag can be added to the the `SOCLIB_GDB` variable to just report watchpoint hit on stderr and avoid stopping the simulation to be less intrusive. 169 169 170 170 * The gdb protocol debug mode may be enabled to dump interaction between client and server: … … 173 173 }}} 174 174 175 * The gdb server almost stops the simulation process when the instrumented virtual processors are frozen. This saves res sources of the host machine during debugging sessions. However this behavior may be an issue when freezing other platform components is not desirable (Use of multiple GDB servers with different processors, critical I/O device latency, multi-threaded simulation... ). The `sleepms` command can be used to tweak the simulator sleep time between each execution cycle when the processors are in frozen state. This value may be set to 0 to let the simulation running at full speed or to -1 to completly stop the simulation while processors are frozen. The `SOCLIB_GDB_SLEEPMS` environment variable can also be used to set this value. An integer ms value is expected. The default value is 100ms.175 * The gdb server almost stops the simulation process when the instrumented virtual processors are frozen. This saves resources of the host machine during debugging sessions. However this behavior may be an issue when freezing other platform components is not desirable (Use of multiple GDB servers with different processors, critical I/O device latency, multi-threaded simulation... ). The `sleepms` command can be used to tweak the simulator sleep time between each execution cycle when the processors are in frozen state. This value may be set to 0 to let the simulation running at full speed or to -1 to completely stop the simulation while processors are frozen. The `SOCLIB_GDB_SLEEPMS` environment variable can also be used to set this value. An integer ms value is expected. The default value is 100ms. 176 176 {{{ 177 177 (gdb) monitor sleepms 10 178 178 }}} 179 179 180 === Flags memo === 181 The following flags can be concatenated in the `SOCLIB_GDB` environment variable (eg, {{{$ export SOCLIB_GDB=SZ}}}) 182 * '''F''': start the simulation in a frozen state so it can be attached with a gdb client 183 * '''X''': disable automatic break whenever an exception is caught, the exception handler will be called transparently 184 * '''S''': make the simulation stop and wait for a gdb attachment whenever an exception is caught 185 * '''C''': dump a trace of every inter-functions branch 186 * '''Z''': same as '''C''' but display only function's entrypoint 187 * '''W''': disable automatic break whenever a watchpoint is hit, just report it on stderr (the watchpoints are to be defined in SOCLIB_GDB_WATCH) 188 189 ---- 190 180 191 More informations on using the GDB client can be found on the [http://sourceware.org/gdb/ The GNU Project Debugger] home page. 181 192