4 This library is an attempt to support the GDB/MI interface. MI stands for
5 machine interface. In this mode gdb sends responses that are "machine
6 readable" instead of "human readable"
11 To implement a C and C++ interface to talk with gdb using it.
16 * The responses should be i18n independent and with less problems to be parsed.
17 * New versions shouldn't break the parser.
22 * The responses are quite complex.
23 * The responses can't be easily read by a human.
28 To add remote debugging to SETEdit. RHIDE lacks it.
30 Currently supported platcforms:
31 ------------------------------
38 The code should be usable by other systems that provides POSIX API and where
41 How to compile and install:
42 --------------------------
44 Change to the "src" directory and run "make". Change to root and run "make
46 The "Makefile" could need changes. The PREFIX is /usr you most probably will
47 want to change it to /usr/local.
52 Switch to the "examples" directory and run "make". Read the comments at the
53 beggining of the examples.
54 They show how to use the library for different targets.
56 * linux_test: Linux console. Shows how to set breakpoints and watchpoints.
57 * remote_test: Remote debugging using TCP/IP connection. Shows breakpoints.
58 * x11_cpp_test: Shows how to use the C++ wrapper. The examples is for X11.
59 * x11_fr_test: Linux X11. Shows how to use "frames" and "variable objects".
60 * x11_test: Linux X11. Shows how to set breakpoints and watchpoints.
61 * x11_wp_test: Linux X11. Shows how to set watchpoints.
63 Function reference and help:
64 ---------------------------
66 An incomplete reference can be found in the "doc" directory. I suggest
67 looking at the examples with the reference at hand.
74 Email: user: set, server: users.sf.net
76 Telephone: (+5411) 4759-0013
80 (1678) Caseros - 3 de Febrero
84 -----------------------------------------------------------------------------
91 1) Remote using TCP/IP: This methode is quite limited. One amazing thing I
92 noticed is that you can't set watchpoints. Other important differences are
93 that the remote target starts "running", it means you have to use continue
94 instead of run and it also means that command line arguments must be provided
96 The way that's implemented you need a full gdb on the local end. That's ok
97 when you want to release the remote end from some of the heavy tasks (like
98 loading all the debug info), but doesn't help if what you want is just
99 control gdb from a remote machine sending the commands throu TCP/IP. The last
100 could allow debugging DOS applications under Windows exploting the Windows
103 2) Local under X: We start an xterm child that runs:
110 That's "xterm -e /bin/sh /tmp/xxxxxx.sh &"
111 Then we read /tmp/yyyyyy file to know the ttyname, delete both files and
112 tell gdb to use this terminal.
113 This is implemented by: gmi_start_xterm()
115 3) Local for Linux console: We can open a new terminal (as X and Allegro
116 does with tty8 and higher).
117 This is implemented by: gmi_look_for_free_vt()
119 4) Local for Linux console, same terminal: We tell gdb to use the current
120 terminal, but before sending an async command we so Suspend and when we get
121 an async response "stopped" we Resume. This is less functional and more