How to Set Environment Variable Within Gdb Using Shell Command

How to set environment variable within GDB using shell command?

Option 2 is possible.

(gdb) unset environment
(gdb) python gdb.execute("set environment Myvar=\xff")
(gdb) show environment 
Myvar=ÿ

Option 1 can be done with env(1).

$ env -i MyVar=$(python -c 'print("xyz")') gdb
(gdb) show environment
MyVar=xyz
LINES=35
COLUMNS=80

Then you just have to clear LINES and COLUMNS.

set environment variable in GDB from output of command

Well, if you really need to do it from GDB, here is one example:

hello.c

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char** argv) {
    printf("argv[1]=%s\n", argv[1]);
    printf("VAR=%s\n", getenv("VAR"));
    return 0;
}

Example:

$ gcc -g -o hello hello.c
$ gdb ./hello
...
(gdb) set exec-wrapper bash -c 'exec env VAR="`echo myEnv`" "$@"' --
(gdb) r myArg
...
argv[1]=myArg
VAR=myEnv

Change VAR and echo myEnv to a variable and command you need.

---

But note that setting VAR from shell before starting GDB also works:

$ VAR=`echo Hey there` gdb ./hello
...
(gdb) r myArg
...
argv[1]=myArg
VAR=Hey there

In GDB, how can I set 'exec-wrapper env' to multiple environmental variables?

You can use

set exec-wrapper env VAR1=val1 VAR2=val2

to set multiple environment variables. The values should be appropriately quoted for your shell, so putting single quotes around them would be a good idea.

In slightly more detail:

The set exec-wrapper command sets a string variable to contain the rest of the command line.

When it comes time to run your executable, gdb does something like the following pseudo-code:

shell_cmd = "exec ";
if (exec_wrapper)
     shell_cmd += exec_wrapper + " ";
shell_cmd += quote_shell_metacharacters(exec_file);
execl(getenv("SHELL"), "sh", "-c", shell_cmd, (char *)0);

So, exec-wrapper can be any command line that makes sense when preceded by "exec " in your shell.

Can a shell script set environment variables of the calling shell?

Your shell process has a copy of the parent's environment and no access to the parent process's environment whatsoever. When your shell process terminates any changes you've made to its environment are lost. Sourcing a script file is the most commonly used method for configuring a shell environment, you may just want to bite the bullet and maintain one for each of the two flavors of shell.

Pass gdb variable to a shell command excuted from gdb

With a new version of gdb, you can use "eval":

(gdb) set $val = 2
(gdb) eval "shell echo %d", $val
2

If you have an older version of gdb, then the best you can do is use "set logging" to write things to a file, then use shell utilities like sed to rewrite the file into the form you want.

How to get environment of a program while debugging it in GDB

The gdb command show environment shows an environment which belongs to gdb [see note], not the environment of the program being debugged.

Calling getenv seems like a totally reasonable approach to printing the running program's environment.

Note

Gdb maintains an environment array, initially copied from its own environment, which it uses to start each new child process. show environment and set environment work on this environment, so set environment will change an environment variable for the next time you start the program being debugged. Once the program is started, the loader will have copied the environment into the program's address space, and any changes made with setenv apply to that array, not the one maintained by gdb.

Addendum: How to print the debugged program's entire environment

On Linux, every process's environment is available through the pseudofile /proc/PID/environ, where PID is replaced by the pid of the process. The value of that file is a list of null-terminated strings, so printing it out takes a small amount of work.

Inside gdb, once you've started running the program to be debugged, you can get its pid with info proc and then use that to print the entire environment:

(gdb) info proc
process 6074
...
(gdb) shell xargs -0 printf %s\\n < /proc/6074/environ
XDG_VTNR=7
KDE_MULTIHEAD=false
...

Of course, I could have done that just as easily outside of gdb, from a different terminal.

Setting up gdb's environment when running it through emacs

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

storing shell output into GDB variable in gdbinit?

If you have a new-ish version of GDB (I believe that means 7.x) with python support built, you could add a section like:

python
import subprocess
gdb.execute('set solib-search-path ' +
    subprocess.check_output('which gdb',shell=True).rstrip() +
    '../project/lib')
end

I can't claim it's not possible without using python, but it's the only way I know of to do it. [I also assumed you meant ../project/lib and not ..\project\lib, but that's an easy change...].

---

Related Topics