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
Related
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.
When I open emacs from a terminal with the emacs& command, I get a lot of debug messages on that terminal. This obscures what I was doing before. Is there a way of suppressing debug message output to the terminal?
Thanks!
Redirect stderr to /dev/null.
emacs 2>/dev/null& command
This alias should to the trick, just put in in .bashrc or your shells rc file.
alias emacs="emacs 2>/dev/null"
It depends on your OS, but you seem to be on Linux.
If it is the case, create a launcher icon, eg for Ubuntu.
This way the desktop environment, like Gnome or KDE, starts the process instead of the terminal, and messages do not appear.
I have a program that I'd like to debug with gdb via emacs. In order to run development versions of this program, I have a shell script that I can source that sets up the calling environment to see the right libraries, etc. What I can't sort out is how to ask emacs/gud to source this file before executing gdb.
I've tried using a command like "source env.sourceme && gdb my_program", but emacs complains that it doesn't know what "source" means. I guess it's not really running gdb in a shell, so these kinds of tricks won't work.
So, how can I convince gud/emacs/whatever to run gdb in my custom environment? I've got a hacky solution in place, but I feel like I must be missing something.
gdb has its own syntax for setting environment variables:
set environment varname [=value]
Instead of a shell script, write your variable definitions in a file using the above syntax, then source the file from a running gdb session. Note that this is not bash's built-in source command, but gdb's own, so naturally bash-style environment variable definitions will not work.
What's your hacky solution?
Why wouldn't you just have a wrapper script that sources env.sourceme and then run gdb?
#!/usr/bin/env bash
source env.sourceme
gdb -i=mi $1
You can modify the Emacs environment using setenv, either interactively (M-x setenv) or programmatically:
(setenv "FOOBAR" "whatever")
When you run gud-gdb, whatever you set using setenv will be passed to the gdb process.
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 using Emacs Tramp for remote development. I think something must be wrong. I had some serious issues with speed when I used ssh:, so I switched to scp:. It seems to work much faster. I tried to run M-x compile with make and it seems to act differently than if I run make directly from a shell prompt. Namely, it is unable to find .h files. It compiles fine from a shell prompt.
Any ideas why this is happening?
Try using M-x tramp-compile explicitly. The keybindings for compilation are automatically remapped when you're editing a remote file with TRAMP, but M-x compile may be operating on the local copy of the files. ?