CDT/Archive/FullGDBConsole

Note: This page was created and last modified before the Full GDB Console was released in CDT 9.2 See CDT/User/NewIn92. The information is obsolete, but the page is preserved to help people in the future working on issues related to the Full GDB Console

Full GDB Console

Controlling GDB through the command-line from within Eclipse has long been a very poor experience. With new support in GDB 7.12, it is now much easier for CDT to provide a full-featured GDB console. This feature is planned for CDT 9.2 for Linux hosts.

Features of full GDB console

The full GDB console provides the user with an identical GDB command-line experience as if GDB was started on a shell

1. Command history
2. Line editing
3. Tab-completion
4. Smart command repeating
5. Full synchronization with the Eclipse GUI

Current status

Development is on-going. The following bugzilla entries and Gerrit reviews are part of this effort:

1. Bug 303808 - Debug console lacks many important features Patch at https://git.eclipse.org/r/#/c/79771
2. Bug 497166 - Support the user using the 'run' command in the gdb console Patch at https://git.eclipse.org/r/#/c/76462
3. Bug 497167 - Direct IO to an eclipse console for a new process created directly from the gdb console Patch (same as above) at https://git.eclipse.org/r/#/c/76462

Trying it out

To try out this feature on Linux:

1. Get setup for CDT development
2. Checkout the latest patchset from https://git.eclipse.org/r/#/c/79771
3. Build GDB from its git repo with the branch corresponding to the upcoming release
   1. git clone git://sourceware.org/git/binutils-gdb.git
   2. cd binutils-gdb
   3. git checkout gdb-7.12-branch
   4. mkdir build.console && cd build.console
   5. ../configure CFLAGS="-g3 -O0"
   6. make -j8
4. Create a launch in Eclipse and point it to the gdb you built in binutils-gdb/build.console/gdb/gdb
5. Launch as usual
6. You should see the new "Debugger Console" view come up with the full GDB console

JUnit test failures

There are many DSF-GDB JUnit test failures once the new console is activated. The failures have been tracked to two issues:

1. GDB pagination was enabled in the full console and was causing even MI output to block. We will turn off pagination all the time. With the user being able to scroll up in the GDB console, having pagination is not that important.
2. Interrupting execution in all-stop mode sends a ^C which now goes do the CLI console instead of the MI console and fails to interrupt. We are investigating what can be done about this.

Things to work on

1. Unable to interrupt in all-stop. According to the GDB experts, the only way around that is to use asynchronous MI.
2. We sometime hit a deadlock when closing the "Debugger console" view and then launching a process using the full console
3. We could create an console page in the old console view saying "The GDB console has been moved to the Debugger Console view", to guide users. This could be removed after a few releases.
4. Should have a search function in console
5. Verify use of fProcess in GDBBackend
6. Starting a new inferior from the GDB console will not perform some initialization steps of DebugNewProcessSequence such as stepInitializeMemory()
7. Do we need any console buttons like the old console (e.g., save)
8. Should killing the console view kill the sessions or keep them in the console manager?
9. Make work on Windows
10. Try to make the prompt more visible after a breakpoint hit, or at least at the beginning of the session
11. Support typing 'run' in the console (started in https://git.eclipse.org/r/#/c/76462/)
12. Redirect to eclipse the output of a process added from the console (started in https://git.eclipse.org/r/#/c/76462/)
13. Synchronizing Debug view selection and GDB console (started in https://git.eclipse.org/r/#/c/77896/)
14. If taking Debugger Console view out of eclipse (in its own window), when typing 'next' we loose the focus which goes back to the main eclipse window. Strangely, if we step over a sleep, the *running event will not cause a loss of focus, but the *stopped event, when it arrives will. We must be doing something different that affects the selection. The problem with this is that the user can type next and then want to type again in the gdb console but this new input will go to whatever view is in focus in the other eclipse window, potentially in the editor. Until we can fix this, I believe we cannot take out the Debugger Console view its parent window.