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.
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.
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
Now I have a question for the mac os. I activated the unattended mode for the installer and tried out this on a win system. There it works fine. Now I wanted to start the installer on a mac os but didn't get it run correctly. I tried the following command:
open MyApp.app --args -q -console -varfile my.varfile
This starts always the GUI installation instead the unattended mode. Maybe the terminal command is incorrect?
Kind regards
Hardie
"/bin/open" is not suitable for command line-style invocations, since the passing of arguments is not synchronous and they are not passed to the main method. Instead, call the executable directly:
MyApp.app/Contents/MacOS/JavaApplicationStub -q -varfile my.varfile
Btw: "-console" is not applicable for Mac OS X, only for Windows.
I'm trying to use gdb with emacs. The library that I'm trying to debug is loaded by a process and can't be run directly. Hence I attach to the process by using the attach command inside gdb. Attaching to a process and setting breakpoints works fine when I use gdb from a shell, but when I use gdb in emacs (by pressing M-x gdb or M-x gud-gdb), it can't set breakpoints. It shows me an error which says "Can't access memory at 0x7efb04". I'm using emacs 23.1.1.
Here is a breakdown of the process I follow:
Press M-x gdb or M-x gud-gdb to launch gdb inside emacs.
Enter the name of the executable built with debugging symbols.
Type "attach [PID]" to attach gdb to a running process.
Set a breakpoint by typing: filename:line number.
The last step gives me an error which says "Can't access memory at 0x7efb04".
Any ideas why this is happening?
EDIT : I get the same error when using DDD (UI for GDB). So I guess it's not an emacs specific issue.
Have you compiled with debug-information? Do you have some code which shows the problem?
Does this happen in other IDEs also?
I figured it out. The problem is with step 2. Entering the name of the executable built with debugging symbol causes the problem. Instead, just launching GDB and attaching to process works fine. I'm not sure if this is the expected behavior.
In DDD, the executable with debugging symbols has to be opened first before we can attach to process. I don't know how to get around that in DDD.
i am trying to use gdb within emacs, i have gdb running but the first command i need to input is for example;
target remote 192.168.1.1:1234
to communicate with the target. I type this in at (gdb) after I have some output from gdb about versions.
For some reason gdb in emacs does not respond to this command and instead does nothing. It works fine on the command line in a shell so i thought it would simply work in emacs aswell.
Does anybody have any ideas as to why this would not work in emacs?
Thanks for your help
what you actually want is to run gdb like this:
M-x gdb ret
gdb --annotate=3 myprog
(gdb) target remote 192.168.1.1:1234
The key appears to be the --annotate=3, I am not sure what tramp is or why you would want to use ssh for anything (gdb will connect directly to the host you pass to it), but this works for me. I was having the same problem connecting to qemu running on localhost.
Have a look at the relevant section of the tramp documentation - you can use Tramp together with gdb to debug remotely. For example:
M-xgdbRET
Run gdb (like this): gdb --annotate=3 /ssh:host:~/myprog RET