Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
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
- Command history
- Line editing
- Smart command repeating
- Full synchronization with the Eclipse GUI
Development is on-going. The following bugzilla entries and Gerrit reviews are part of this effort:
- Bug 303808 - Debug console lacks many important features Patch at https://git.eclipse.org/r/#/c/79771
- Bug 497166 - Support the user using the 'run' command in the gdb console Patch at https://git.eclipse.org/r/#/c/76462
- 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:
- Get setup for CDT development
- Checkout the latest patchset from https://git.eclipse.org/r/#/c/79771
- Build GDB from its git repo with the branch corresponding to the upcoming release
- git clone git://sourceware.org/git/binutils-gdb.git
- cd binutils-gdb
- git checkout gdb-7.12-branch
- mkdir build.console && cd build.console
- ../configure CFLAGS="-g3 -O0"
- make -j8
- Create a launch in Eclipse and point it to the gdb you built in binutils-gdb/build.console/gdb/gdb
- Launch as usual
- 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:
- 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.
- 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
- Unable to interrupt in all-stop. According to the GDB experts, the only way around that is to use asynchronous MI.
- We sometime hit a deadlock when closing the "Debugger console" view and then launching a process using the full console
- 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.
- Should have a search function in console
- Verify use of fProcess in GDBBackend
- Starting a new inferior from the GDB console will not perform some initialization steps of DebugNewProcessSequence such as stepInitializeMemory()
- Do we need any console buttons like the old console (e.g., save)
- Should killing the console view kill the sessions or keep them in the console manager?
- Make work on Windows
- Try to make the prompt more visible after a breakpoint hit, or at least at the beginning of the session
- Support typing 'run' in the console (started in https://git.eclipse.org/r/#/c/76462/)
- Redirect to eclipse the output of a process added from the console (started in https://git.eclipse.org/r/#/c/76462/)
- Synchronizing Debug view selection and GDB console (started in https://git.eclipse.org/r/#/c/77896/)
- 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.