Question

我正在弄清楚从GDB启动应用程序会导致符号查找错误的问题，但是从shell启动它会起作用。

事实证明，无论何时从GDB内部启动程序，它都会启动一个新的shell，从而覆盖我在启动GDB之前设置的所有环境变量（如LD_LIBRARY_PATH）。

这不是我想要的行为。有人可以解释这背后的理由，或者告诉我如何解决这个问题？

Answer 1

我猜你无条件地在LD_LIBRARY_PATH等中设置了~/.cshrc。因此，如果从shell提示符执行此操作：

export LD_LIBRARY_PATH=foo  # or for csh:
setenv LD_LIBRARY_PATH foo
$SHELL -c 'echo $LD_LIBRARY_PATH'

结果不是foo。不要。

通常这种情况发生在CSH用户身上，他们忽略了保护他们的~/.cshrc免受非交互式shell攻击。设置BASH_ENV。

的BASH用户也可能会遇到这种情况

Answer 2

我遇到了同样的问题。我在inferior.h中找到了（gdb gdb/inferior.h的源代码）有一个宏STARTUP_WITH_SHELL，还有一段评论

/* If STARTUP_WITH_SHELL is set, GDB's "run"
   will attempts to start up the debugee under a shell.
   This is in order for argument-expansion to occur. E.g.,
   (gdb) run *
   The "*" gets expanded by the shell into a list of files.
   While this is a nice feature, it turns out to interact badly
   with some of the catch-fork/catch-exec features we have added.
   In particular, if the shell does any fork/exec's before
   the exec of the target program, that can confuse GDB.
   To disable this feature, set STARTUP_WITH_SHELL to 0.
   To enable this feature, set STARTUP_WITH_SHELL to 1.
   The catch-exec traps expected during start-up will
   be 1 if target is not started up with a shell, 2 if it is.
   - RT
   If you disable this, you need to decrement
   START_INFERIOR_TRAPS_EXPECTED in tm.h. */
#define STARTUP_WITH_SHELL 1
#if !defined(START_INFERIOR_TRAPS_EXPECTED)
#define START_INFERIOR_TRAPS_EXPECTED   2
#endif

然后我将STARTUP_WITH_SHELL设为0并递减START_INFERIOR_TRAPS_EXPECTED 并重新编译我的gdb。之后，gdb不再从shell启动了。

Answer 3

当你从shell启动gdb时，你将它作为一个新进程启动，没有办法解决这个问题。在Unix中，新进程继承了父进程的一些环境。

要确保继承变量，如果您使用的是类似bourne的shell，请尝试导出它：

export LD_LIBRARY_PATH=...

Answer 4

调试对象（gdb用语中的 inferior ）始终以干净的环境启动，以获得更可重现的结果。要在那里设置变量，请使用

set env VARNAME=VALUE

跑步前的

命令。

为什么GDB启动一个新shell以及如何禁用此行为？

4 个答案: