I need to debug a program on a server and would like to still have its output in GDB.
The following "works" in general:
manual started (terminal) task that opens a ssh connection, does the necessary pre-setup (server-side scripts), then runs gdbserver --multi :12345
GDB debug configuration that runs in attach mode and executes the appropriate command chain "set sysroot remote:", "target extended-remote myserver:12345", "set remote exec-file /path/to/myfile", "run"
I know see the program running and stopping on the breakpoint, see the program's output in the integrated terminal and can toggle to the debugging console. But how can I see both the debugging console and the integrated terminal at once?
If somehow possible I'd like to not use an external window for one of those, as there are multiple vscode instances open - each connecting to a different server - and multiple windows "mgically" belonging to each other would make debugging harder together - the integrated option solves this problem completely.
The Views and Panels (Problems - Terminal - Output - Debug console) can be moved.
Click on the header/Tab of the View/Panel and drag the mouse to the new location.
The mouse pointer will change if it is possible to drop it.
You can restore a panel/view to the original location from the context menu on the top-bar.
I have looked in the doc but could not find any mentioning of this. It was mentioned in one of the Release notes.
Related
In VS Code V1.73.1 - I am running GDB (actually a RISCV variant, debugging a target board vi jtag).
I"m also quite a bit confused and do not know if this is a VSCODE problem or a plugin problem, and there are multiple plugins involved,
If it is a plugin then I'm thinking it is the one that controls GDB... and other things are built upon that plugin. But - GDB is so much at the core that I think that the GDB component is actually part of the baseline VS-CODE package.
Background: I want to halt the cpu I am debugging so that i can inspect global variables and/or set breakpoints. I cannot seem to do that.
I normally go through the connect, load, then type continue. If I set a breakpoint before I type continue - it works.
My code is now running, I want to stop - add a breakpoint and continue.
To be clear - I do not mean disconnect and stop debugging, I want to stop or halt the cpu at its current location.
The normal method or action for GDB is to type Control_C in the GDB terminal but - this is VS Code, its not a normal terminal.
The question is how do I stop or halt the cpu under control of the debugger
Its not obvious, and no menu seems to find that selection.
if it was an local debug session I could do something like controlC in a console window or use KILL to send a signal, but - this is an embedded/remote GDB session so that is not possible.
Ideally, the integrated VS Code terminal, depending on the context, the type of the folder and the extension, executes some commands. For example, when opening a folder containing a Python virtual environment in VS code, the environment is recognized and activated (by the python extension) by default when opening a new integrated terminal instance (situation 1). This is done by running some command similar to source /path/to/venv/bin/activate.
Or, when using the ROS extension to debug nodes, selecting "Start Debugging (F5)" uses the launch.json file to start some nodes and finally starts debugging the desired code. To do so also, there is some command that is executed (also by he ROS extension, I assume) in the integrated terminal (situation 2) to start the debugging process. In case of debugging ROS nodes, the command usually looks something like /usr/bin/env /bin/sh /tmp/someFileName.
But, unfortunately, both of the above mentioned situations fail. I believe this happens because while the extension tries to run these two commands within their respective integrated terminals, the commands do not actually get executed in either situation. Instead, these commands are printed on the top of the terminal, but the state of the terminal is unchanged (as opposed to when the commands would have been executed, in which case depending on the commands some actions are performed). Here are two images to show what I mean. Top, situation 1 and bottom, situation 2.
The fact that these two commands are printed on top of the terminal as soon as the a new terminal instance is opened tells me that the extension tries to execute them, but they do not work for some unknown reasons.
Just to be clear, both of them are run in a seperate VC Code window, they have nothing to do with each other. When I manually run both the commands in their respective terminals I do get the desired results.
Now, I am unsure exactly how to name this issue. But I think this is surely an issue with the integrated terminal, and not a problem of the extensions. I am not sure how one could reproduce this problem.
I did a clean reinstall of VS code by deleting %APPDATA%\Code and %USERPROFILE%\.vscode. Because I am using this on WSL, there is only ~/.vscode-server on the ubuntu side. I manually uninstalled all extensions on WSL but did not delete this folder, in fear of breaking something. The problem still persisted. I have also created an issue on the VS Code GitHub page with nearly the same information.
I am unsure if this is a bug or is there something wrong with my settings. Does anyone know how I could fix this? For smaller use-cases I can still manually enter the command in the terminal. But I am trying to debug a ROS application with nearly 10 different terminals opening up and I cannot be manually entering the command each time to restart the process.
Please let me know if you need any more information. Many thanks in advance.
Edit: both edits to frame the question properly.
Although not related to WSL, I dug a little deeper today as to why in my case the extension commands were not being executed or were being chopped.
I'm an iTerm2 user. iTerm2 has something called Shell Integrations, which allow iTerm to behave differently under certain circumstances, for example, adding markers to each prompt or coloring output with certain text (e.g. WARNING or ERROR)
From time to time, I also use the VSCode Integrated Terminal, which recently added support for reporting whether the previous command errored out with an indicator on the gutter of the Integrated Terminal panel using the exit code.
iTerm can do something similar but the shell integrations mess up completely the VSCode functionality and therefore I changed my .bashrc file to detect if the terminal emulator was iTerm2 or not (which can be done with the it2check utility of iTerm2) so that it only sourced the shell integrations if I was using iTerm2.
The problem is that it2check "eats" some STDIN bytes using dd, specifically, until it finds an n so that it can obtain the name of the emulator. This of course chops the commands on the STDIN until the first n and makes VSCode Extension Terminal commands unusable
The workaround I came up with is to use the value of "$TERM_PROGRAM" as means to distinguish between the different programs. The only caveat is that the value won't be passed if you're inside of a tmux session or similar, but I can live with that.
In your case, I'd check for any process that is either not passing the STDIN to the WSL process or any dot files or shell profile scripts eating up the STDIN they receive.
I suspect that the real problem is that the local process doesn't relay the STDIN contents to the WSL and as a workaround you may try to create a VSCode Integrated Terminal profile that uses SSH to connect to the WSL host so that the STDIN is preserved
I would like to F11 a python file in Eclipse and when I hit a breakpoint automatically enter the Python Interactive Console (not the default pydev debug console).
I understand that I could upon entering debug mode open a new interactive python console (I have turned on the connection between the interactive console and the debug console) and work from there. But not only is that an extra step but it is frustrating because everytime I interact with such an interactive console it shoves me back to the debug console! Then I have to go review the interactive console. I also understand that I could do a 'runfile' from within the interactive console, but I really want to use the convenient F11 capacity of eclipse to just be in an editor, hit F11 and when I break enter the interactive console.
Basically I would like the Interactive Console to be my debug console. Possible?
If the F11 approach is not possible, is there another approach? My goal is to get my history of command typing available to me with arrow keys. Not possible in the default python debug console from what I can tell. Perhaps if I made the pydev debug console ipython?
Thanks, I have searched a lot on this but can't come up with a solution.
from PyDev 3.9.2 onwards, a console prompt with history, code-completion, etc. will appear automatically.
See: http://pydev.blogspot.com.br/2015/02/pydev-392-released.html for details.
I have ipython working in pydev when using the normal interactive console, however when entering debug mode the console reverts to the standard pydev console. If I close this console and re-open it, ipython returns and I can use it as normal. Am I missing something, or is this a bug?
-Eric
Actually since PyDev version 3.0 you can attache a IPython console to a debug-session:
http://pydev.org/manual_adv_interactive_console.html#full-debug-support-in-interactive-console
To enable that feature, go to window > preferences > PyDev > Interactive Console and check 'Connect console to Debug Session?'.
Then only hassle is that you have to re-open a new IPython-console every time you re-launch the program in debug-mode.
Actually, Eclipse itself can have multiple consoles open at the same time... if you want, you can create multiple console views and pin a different console to each view (if you don't pin the console, one console will be shown on top of the other and you'll have to do the switching from one to the other manually).
As it is now, the debug console is not the same as the interactive console (it's a simpler version because of issues with the eclipse integration, although there are plans to be able to attach an interactive console to a debug session).
So, what you described is what should really happen (not really a bug).
I'm currently writing some ncurses code and the native Eclipse (3.2.2) console can't display its graphics. I'd instead like to run the program through xterm. What I want is to be able to start xterm and run from there. I'd prefer to not get involved with any plugins or that jazz. Just something simple.
EDIT
So I have the answer and it was pretty simple...
Run -> External Tools -> External Tools -> New Launch Config...
Then select location of your terminal emulator. /usr/bin/gnome-terminal in my case.
after that set the appropriate arguments. "-e ~/ncurses/start" in my case.
Then make sure you aren't allocating a console by unchecking that option in the "Common" tab.
Annon add to his question:
its a pain to keep switching back and forth from eclipse and the terminal. I'm looking for a way to just hit something like"F5" and have it run my ncurses program in a new xterm terminal process
The simplest way to do that is to report the command line into an external tool configuration, and point eclipse to use a shell (like described in this program)
In the argument, you will add the command line eclipse execute (command line which can be retrieved as mentioned in the second part of this answer below).
Of course, replace 'cmd.exe' by the shell of your choice, and try not setting the 'Allocate Console' checkbox in the Common tab of that external launcher.
To launch through a xterm, without eclipse involved (not what you are asking for, just keep here for archive)
You can launch your program through Eclipse (Run Configurations), and observe through a 'ps' command the exact Java command line used.
Or launch it in debug mode, and right click the task in Debug view and open Properties. It will show the command line, as documented here.
Then launch that command line directly in your console (Eclipse being not involved at all at this point).