I've established a build process that makes binaries and then separates the debug info from them (build-ids are enabled).
The build can also generate the .gdbinit files with the lines like set debug-file-directory <dir>, so the debugger can find them (there are lots of executables and libraries in the project).
But when I run $ gdb myprogram, gdb can't find the symbols. I have to do (gdb) file myprogram to redo the search for the debug-symbols file. It seems that .gdbinit is executed after opening myprogram.
How to make it automatic?
Basically, .gdbinit file is used to setup debugging environment (add aliases for long commands, load custom commands, setup print modes, etc. ), not a particular debugging session.
Taking a look at gdb startup order and considering that home .gdbinit works ok, it cannot be achieved with local .gdbinit file (order of operations should be set debug-file-directory, file). I think you can modify your build/debug process for using gdb wrapper script with gdb command script (the same as .gdbinit but call it start.gdb for example to avoid confusion):
gdb_x:
#!/bin/sh
gdb -x ./start.gdb "$#"
start.gdb:
# this file is generated for .. by ...
set debug-file-directory <>
set debug-file-directory <>
Or, as a workaround, if you can bare with the fact that commands will run twice:
gdb -x ./.gdbinit <>
which can be avoided with (and deserves again wrapper script):
gdb -iex "set auto-load local-gdbinit off" -x ./.gdbinit <>
Related
This is bothering me more than it should and has me completely stumped. I feel like like finding the answer will have some good learning opportunities so hopefully it's relevant.
I do embedded C development with Vim and have a setup for hobbyist stuff with Arduino (using Arduino Makefile). I use :make with some shortcuts with build projects.
An external define resolves the Arduino Makefile root directory in the project level Makefile: 'ARDMK_DIR=/usr/local/opt/arduino-mk'. This is define as an export in my shell (zsh). This is where it gets weird:
Using make at the shell prompt the project builds fine:
make -d
This program built for i386-apple-darwin11.3.0
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/usr/local/opt/arduino-mk/Arduino.mk' (search path) (no ~ expansion)...
However using :make in Vim the define becomes something from an old install:
:make
This program built for i386-apple-darwin11.3.0
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/usr/local/Cellar/arduino-mk/1.5.2/Arduino.mk' (search path) (no ~ expansion)...
Makefile:24: /usr/local/Cellar/arduino-mk/1.5.2/Arduino.mk: No such file or directory
I cannot for the life of me find where ARDMK_DIR is being re-defined to '/usr/local/Cellar/arduino-mk/1.5.2'. Things I have tried:
setlocal makeprg=echo\ $ARDMK_DIR\ &&\ make\ -d\: echo comes back with my shell define (/usr/local/opt/arduino-mk), but make fails with the error above!!
:echo $ARDMK_DIR: again returns my shell define.
ag my home directory for ARDMK_DIR, the only place it is defined is in my shell exports. Did since for my root directory to and same thing. Same thing for $VIMRUNTIME
Even vim-disptach works fine calling the same makeprg?!
Re-define ARDMK_DIR in the project Makefile. Everything builds find as expected. I don't want to do this however as I compile with different systems.
The same vim config works on other macOS and Linux systems with expected behaviour.
Some where between echo and the actual execution of make, ARDMK_DIR is being re-defined. Why and can anyone think of a way of finding out where and solving this?
Zsh has multiple init files that are sourced. The file .zshenv is always sourced, when the shell starts and the file .zshrc is only sourced when the shell is started in interactive mode.
If you define the variable ARDMK_DIR with different values in .zshenv and in .zshrc, the value from .zshrc will be used when you work interactive with the shell (entering commands, starting Vim, ...).
But when Vim starts a command it will start a non-interactive shell. In that case only the file .zshenv will be sourced, so you get the value from that file.
One question left:
Why did the following command first echo the correct value, but make uses the wrong?
:setlocal makeprg=echo\ $ARDMK_DIR\ &&\ make\ -d\
For testing, I started Vim under strace. Then :
:set makeprg=echo\ $EDITOR
:make
In the strace file I found the following line:
execve("/usr/bin/zsh", ["/usr/bin/zsh", "-c", "echo vi 2>&1| tee /tmp/vdxR5DH/"...], [/* 86 vars */]) = 0
As you can see, Vim executes echo vi, so it already expanded the environment variable $EDITOR to its value before calling the shell.
So the answer to the above question is, that the echo command echos the text, that Vim inserted into the command line while the make command gets the the variable value from the environment. As it is a non-interactive shell, it is the value from .zshenv.
I've got this EFL file which I need to debug/step-through. It's a reverse engineering competition. All I need to do is to find out the value of a register at a particular point in time and in a particular place. I used Hopper Disassembler to find out the address of interest.
Here's the problem. I don't know how to debug an ELF file. It's my first time debugging in a Linux environment. Learning how to execute the ELF file itself took me a while. I execute by using
ld-linux.so.2 ./[EFLFILE] [arguments]
Is there a way I can atleast attach a debugger onto the proess? I can't even find it with the ps command. Also, I've heard that it's possible to have remote debugger; to have a debugger running on a windows machine and have the binary to be examined running on a linux.
Could anyone help me achieve just any of this?
Usually an ELF file can be executed as follows:
$ /path/to/elffile [arguments]
To debug it using GDB you can do:
$ gdb /path/to/elffile
Or passing arguments:
$ gdb --args /path/to/elffile arguments...
In your case:
$ gdb --args ./[EFLFILE] [arguments]
Then type run or simly r and press < Enter >.
Type help to get help on the gdb commands.
Note: if your program needs some external libs, before running it, you should define LD_LIBRARY_PATH pointing on the folder containing those libs (export LD_LIBRARY_PATH=/the/path/to/libs)
Is there a way to automatically start a process under gdb on Linux? An equivalent of setting the Image File Execution Options on Windows.
I am trying to debug start-up phase of a process that is launched from another one.
I would normally move the real program out of the way, and replace it with a script that launches the program under GDB with the same parameters.
#!/bin/bash
exec gdb -args <realprog> "$#"
If that doesn't work due to the output being redirected to file, or something, then try this:
#!/bin/bash
exec xterm -e gdb -args <realprog> "$#"
That should give you a pop-up terminal with GDB running inside.
You don't have to go through all that registry voodoo on Linux :)
Simply:
1) Rename your program
2) Write a shell script that calls gdb with your (renamed) program and passes any arguments you want. Make sure you "chmod +rx" your script.
3) Name the shell script the original name of your program, and put it in the same directory as your program
4) Execute!
I am looking to set up the path for the source code when debugging with gdb. I chose to do that with a .gdbinit file.
Basically, it contains a command:
directory="/path/to/src".
However, I would like to be able to specify that command as:
directory="$SOURCESROOT/src"
where SOURCESROOT is an environment variable. And, if possible, being able to do that inside gdb debuuging session too, by entering directory=$SOURCESROOT/folder.
Basically, I am looking to access inside gdb (or inside .gdbinit) the environment variables.
But not the environment of the debugee (set env and so on), but the environment of the gdb itself (ie. of the bash prompt where I type in the first place "gdb program").
While typing shell $SOURCESROOT inside gdb session shows the content of the environment variable, this is quite useless, as I cannot enter: directory=shell $SOURCESROOT.
PS: Anybody found an ideal setup for Linux (Debian) to download the sources with "apt-get source", to update those with some kind of "apt-get update" utopic command and to install them so that gdb will automatically find these sources?
Nevermind, I found how to do it by using Python scripting.
My .gdbinit file is now:
python
import os
gdb.execute('directory' + os.environ['SOURCES'] + '/package_name/src')
end
show directories
(6 year late!)
Don't use .gdbinit for this purpose. It does not expand env vars. Instead, use this commandline to launch gdb:
gdb --init-eval-command="set dir $SOURCESROOT/src"
(gdb) show dir
/path/to/src
FYI this technique can be used to set other critical variables, e.g
gdb --eval-command="set sysroot $SYSROOTDIR"
Which sets sysroot and solib-absolute-prefix in gdb
If you don't want to involve python, then this could work?
"show environment [varname]
Print the value of environment variable varname to be given to your program when it starts. If you do not supply varname, print the names and values of all environment variables to be given to your program. You can abbreviate environment as env."
ftp://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_19.html
Maybe they could be used for conditions as well:
https://www.adacore.com/gems/gem-119-gdb-scripting-part-1
In my case I'd like to set global history in common $HOME/.gdbinit, so I used
set history filename ~/.gdb_history
instead of
set history filename $HOME/.gdb_history
I've just tried using gdb on BackTrack Linux and I must say that its awesome. I wonder how gdb in backtrack is configured to act this way.
When I set a breakpoint, all the register values, a part of the stack, a part of the data section and the next 10-15 instructions to be executed are printed. The same happens when I step or next through the instructions.
I find this amazing and would love to have this on my Ubuntu machine too; how could I go about doing this?
They seem to be using this .gdbinit file:
https://github.com/gdbinit/Gdbinit/blob/master/gdbinit
I'm guessing that this is done using a post command hook:
http://sourceware.org/gdb/current/onlinedocs/gdb/Hooks.html#Hooks
inside of a system wide gdbinit:
http://sourceware.org/gdb/onlinedocs/gdb/System_002dwide-configuration.html
which may or may not reference shell commands and/or use gdb python scripts.
try:
strace gdb /bin/echo 2>&1 | grep gdbinit