This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH 00/23] Towards great frontend GDB consoles
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 3 Feb 2016 16:43:35 +0000
- Subject: [PATCH 00/23] Towards great frontend GDB consoles
- Authentication-results: sourceware.org; auth=none
This series provides a way to for Eclipse and other frontend's GDB
console to be on par with gdb's native console running on a terminal.
The current support for implementing a GDB console that MI frontends
have available, based on "-interpreter-exec console", leaves readline,
history, completion, when to show/hide/print the prompt (sync vs async
execution), pagination, etc. all up to the frontend.
The end result is that all frontends have a real bad GDB console
experience, if they provide one at all.
GDB already has to handle all that for the native CLI, when GDB is
started without MI. This series leverages that. Instead, have
Eclipse create a pty and wrap it in a window widget -- the same as
Eclipse's shell console -- and start GDB in that pty. Then, create a
second pty for MI communication, and tell GDB to start a MI
interpreter there, with a new "new-ui mi /dev/pts/N" command.
GDB then creates/manages a CLI on its terminal, with readline,
history, etc., support all done by GDB.
It's also possible to start extra CLI consoles, with "new-ui console
/dev/pts/N". The current limitation is that these extra consoles
don't have readline active (work as if "set editing off"), because
there can only be one instance of readline in a process, currently. I
have a readline patch that addresses it, but it'll need discussion and
it may be get accepted or the design may need to change. It should be
possible to start gdb in MI mode, and then start an extra console, and
support readline on that console (since there's still just one
readline user), though it'll need a little bit more work to get there.
I just didn't try it yet, but it's definitely possible.
My original prototype did start out by doing things the other way
around -- start GDB in MI mode, and then start an extra CLI console on
separate tty. I handed over that (functional) prototype to Marc
Khouzam @ Eclipse CDT a while ago, and after experimentation and
discussion, we ended up concluding that starting GDB in CLI mode
instead was both easier and actually also makes it possible to support
an interesting use case -- connect an Eclipse frontend to a GDB that
is already running outside Eclipse. Say, you're debugging on a
terminal, and then suddendly decide to start Eclipse's Standalone
Debugger _reusing_ your existing GDB, without having to start the
debug session from scratch. Magic.
The current usage is "new-ui <interpreter> <tty>".
E.g., on a terminal run this scriplet:
$ cat gdb-client
#!/bin/bash
reset
tty
tail -f /dev/null
$ gdb-client
/dev/pts/15
Now run gdb on another terminal, and tell it to start a MI interpreter
on the tty of the other terminal:
...
(gdb) new-ui mi /dev/pts/15
New UI allocated
Now back to the the gdb-client terminal, we'll get an MI prompt, ready
for MI input:
/dev/pts/15
=thread-group-added,id="i1"
(gdb)
You can also start a new UI running a CLI, with:
(gdb) new-ui console /dev/pts/15
More details in the last patch of the series (which actually adds the
command).
This still misses ChangeLog entries, some comments, and documentation
changes. And I haven't thought about tests yet.
Marc asked if he could try the current version of this series, to try
to get support for this on the Eclipse side ASAP, and maybe show it
off at EclipseCon in a few weeks, so here it is, supposedly fully
functional and all cleaned up ready for Eclipse testing, and general
feedback. :-)
Pedro Alves (23):
Test issuing a command split in multiple lines with continuation chars
Command line input handling TLC
Introduce "struct ui"
Make gdb_stdout&co be per UI
Make the interpreters be per UI
Introduce interpreter factories
Make the intepreters output to all UIs
Make instream and serial_stdin be per UI
Make input_fd be per UI
Make outstream be per UI
Delete def_uiout
Make current_ui_out be per UI
Make command line editing (use of readline) be per UI
Always process target events in the main UI
Make target_terminal_inferior/ours almost nops on non-main UIs
Introduce display_mi_prompt
Simplify starting the command event loop
Make gdb_in_secondary_prompt_p() be per UI
Replace the sync_execution global with a new enum prompt_state
tristate
New function should_print_stop_to_console
Push thread->control.command_interp to the struct thread_fsm
Only send sync execution command output to the UI that ran the command
Add new command to create extra console/mi UI channels
gdb/annotate.c | 15 +-
gdb/breakpoint.c | 21 +-
gdb/cli/cli-interp.c | 253 ++++--
gdb/cli/cli-interp.h | 32 +
gdb/cli/cli-script.c | 27 +-
gdb/common/buffer.h | 8 +
gdb/compile/compile.c | 14 +-
gdb/defs.h | 2 -
gdb/event-loop.c | 2 +
gdb/event-top.c | 731 ++++++++--------
gdb/event-top.h | 18 +-
gdb/exceptions.c | 4 +-
gdb/gdbthread.h | 5 -
gdb/guile/guile.c | 14 +-
gdb/guile/scm-ports.c | 6 +-
gdb/inf-loop.c | 2 +-
gdb/infcall.c | 43 +-
gdb/infcmd.c | 102 ++-
gdb/inflow.c | 40 +-
gdb/infrun.c | 137 ++-
gdb/infrun.h | 10 +-
gdb/interps.c | 252 ++++--
gdb/interps.h | 48 +-
gdb/linux-nat.c | 2 -
gdb/main.c | 56 +-
gdb/mi/mi-interp.c | 946 +++++++++++++--------
gdb/mi/mi-main.c | 2 +-
gdb/python/python.c | 15 +-
gdb/remote.c | 2 -
gdb/target.c | 27 +-
gdb/terminal.h | 6 +-
.../gdb.base/command-continuation-char.exp | 34 +
gdb/testsuite/gdb.gdb/selftest.exp | 4 +
gdb/thread-fsm.c | 12 +-
gdb/thread-fsm.h | 23 +-
gdb/thread.c | 2 +-
gdb/top.c | 467 +++++-----
gdb/top.h | 155 +++-
gdb/tui/tui-interp.c | 173 +++-
gdb/tui/tui-io.c | 4 +-
gdb/ui-file.c | 4 +-
gdb/ui-file.h | 4 +-
gdb/ui-out.c | 184 ----
gdb/ui-out.h | 3 +-
gdb/utils.c | 4 +-
gdb/utils.h | 19 +-
46 files changed, 2303 insertions(+), 1631 deletions(-)
create mode 100644 gdb/cli/cli-interp.h
create mode 100644 gdb/testsuite/gdb.base/command-continuation-char.exp
--
1.9.3