Changes between Version 17 and Version 18 of Tools/Gdb Server

Timestamp:

Nov 21, 2009, 2:26:31 PM (16 years ago)

Author:

becoulet

Comment:

--

Tools/Gdb Server

@@ -121 +121 @@
 
  * Managed processors begin executing code at simulation startup until a gdb client connect on port 2346.
- * Processors may be forced to start in frozen state waiting for incoming gdb connection by setting the `SOCLIB_GDB` environment variable to `START_FROZEN`.
+ * Processors may be forced to start in frozen state waiting for incoming gdb connection by adding the `F` flag to the `SOCLIB_GDB` environment variable.
  * All the managed processors are frozen at the same time when the gdb client prompt is displayed.
  * When using the `continue` command, all processors resume at the same time.
@@ -131 +131 @@
 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:
 
+ * The !GdbServer may be instructed to dump every inter-function branch to produde 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:
+{{{
+(gdb) monitor calltrace 0         # disable for all processors
+(gdb) monitor calltrace 1 2       # enable for thread 2, processor 1
+}}}
  * The processor (thread id) used for step by step execution may be forced for the next '''single step''' operation:
 {{{
 (gdb) monitor stepcpu 1
 }}}
- * The GdbServer may be instructed to break on processor exception or to let the processor jump in its exception handler transparently. When used with an extra parameter, this setting can apply to a single processor instead of all. The following command disables exception catching for thread id 2 (processor 1): 
+ * The !GdbServer may be instructed to break on processor exception or to let the processor jump in its exception handler transparently. When used with an extra parameter, this setting can apply to a single processor instead of all: 
 {{{
-(gdb) monitor except 0 2
+(gdb) monitor except 1            # enable for all processors
+(gdb) monitor except 0 2          # disable for thread 2, processor 1
 }}}
  * 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 modifiy 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.