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.
Related
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.
I'm using GDB 8.0.1 on Mac OS High Sierra 10.13.3. Basically, doing:
(gdb) r < some_input_file.in
ignores the input file. It acts as if the command ran was simply
(gdb) r
The closest thread I found about this problem was Input redirection from file gdb but no solution was posted.
Any clues?
Thanks!
You are probably running into an interaction between gdb and macOS SIP ("System Integrity Protection").
gdb implements run redirections by passing the command line to the shell; then it waits for the shell to invoke your program before starting to "really debug". The shell is actually still controlled by gdb using ptrace -- gdb uses this to observe the eventual exec and to ensure that your process is also traced.
However, SIP prevents certain programs from being traced, and in particular programs in /usr/bin, like most shells. This causes run to stop working entirely, because the shell can't be started.
So, to make gdb continue to work, users often set startup-with-shell off. Perhaps whatever gdb build you are using does this by default (or maybe, like me, you put this in your .gdbinit and forgot about it). This setting lets run work -- but at the cost of disabling redirections.
There's a gdb bug for this which you can follow.
I am trying to set up Emacs and GDB such that I can have the gdb-many-windows option running. However, m-x gdb hangs after running any binary, and Emacs starts consuming 100% CPU and becomes unresponsive.
I am running on:
OS X 10.10.1.
Emacs 25.0.50 (the one in Homebrew)
GDB 7.8.1 (the one in Homebrew)
My Emacs setup is here: https://github.com/ChrKroer/emacs-setup
Here's what happens:
I run some binary with m-x gdb and then 'gdb --i=mi [name of binary]'. Everything works fine, the correct windows set up and everything. I then give the command 'run' to GDB, and it runs the code correctly. But once the code finishes, Emacs becomes unresponsive and start consuming 100% CPU power. This happens even with a simple hello world program. I have tried giving various options like --annotate=3, --fullname etc.
If I instead run m-x gud-gdb, I can run the same binary just fine, gdb exits normally and I can continue using Emacs.
Any help would be much appreciated.
The bug is confirmed in my mac. What's more, emacs with the same configuration (actually no configuration at all) works well in my Linux machines. So it is a bug related to Mac OS X.
Update:
It seems that some modes/plugins in emacs which conflicts with "gdb". When I run it without loading anything in .emacs, it stops hanging emacs when gdb debug finished.
I will try to track which mode causes such problems, and report it here.
It seems that many modes could lead to freezing emacs when gdb finishes debugging, e.g. "helm" and any modes using helm, "function-args" (which enables some features of helm in its source codes)
To my configuration, dozens of modes enable, helm is the critical mode that cause gdb to freeze emacs when it reaches the end.
It's not due to helm, but due to semantic-mode, which might be enabled when you want to use helm-semantic-or-imenu.
Conclusions:
It is caused by semantic-mode, which performs poorly in Mac OS X, even its basic functionality has bugs. Under Linux, it doesn't have any obvious issues, that's why gdb works in Linux. Search around your .emacs and make sure disable all semantic-mode, then it should work.
Note that, even though you disabled semantic-mode before run gdb, if semantic-mode is initially enabled, it will still freeze emacs. semantic-mode has be initially disabled.
Thanks to thierryvolpiatto for help in debugging:
https://github.com/emacs-helm/helm/issues/1168#issuecomment-140132443
I'm having an issue when attempting to analyze variables in the Eclipse IDE, while in debug mode. At a breakpoint, I'll try to expand a data structure, in the Eclipse variables window, however, the member doesn't display and the program running on the board seems to crash. Once this happens, the only way to reconnect over the jtag is to reboot the board and restart Eclipse.
Without knowing for certain, it seems to be an error with memory allocation in the IDE, but I don't know. Is this a common problem when debugging over jtag? Where might I begin looking to resolve the issue?
I'm using Eclipse on Windows, with the PyDev plugin for Python development. When I use 'Run' to start my application, it spawns a new Python (CPython) instance. When I use the 'terminate' button (red square), it kills the process. However, it appears to do a SIGKILL, so my shutdown handler is unable to clean up.
Is there any way to get Eclipse to send a SIGTERM, or simulate a keyboard interrupt (ctrl-c) from the Eclipse console?
Note: I'm aware there are other Python IDEs like Komodo or Wing that might solve this problem, but I'm not looking to switch over this.
Eclipse uses the Java Process API which sends the signal. This is a native API and there is no way to change that. I assume that you've tried to install a handler for SIGKILL, too, and that didn't work.
Therefore, the only solution would be to write a small batch file which lists the processes and sends SIGTERM to one of them. Invoke that from a command prompt. If you use Alt-Tab to switch to it, it's almost as comfortable as doing it from inside Eclipse.
Or write a plugin to invoke batch files.
I looked at How can a Java program get its own process ID? and came up with this.
System.out.println("kill -SIGINT "+ProcessHandle.current().pid());
I realize this isn't ideal if you don't want it printing this out for production but if you're just prototyping it's handy. Or you could put it inside an if that only runs if you're debugging.