¿Por qué GDB inicia un nuevo shell y cómo deshabilitar este comportamiento?

Question

Estaba averiguando un problema en el que iniciar la aplicación desde GDB da como resultado un error de búsqueda de símbolos, pero comenzar desde el shell funciona.

Resulta que siempre que inicie un programa desde dentro de GDB se iniciará un nuevo shell y anulará todas las variables de entorno que había establecido antes de iniciar GDB (como LD_LIBRARY_PATH).

Esto no es realmente el comportamiento que quiero. ¿Puede alguien explicar la razón detrás de esto, o decirme cómo puedo apagar esto?

Answer 1

que supongo que incondicionalmente configurar LD_LIBRARY_PATH en su ~/.cshrc o similares. Así que si desde un shell le pide que haga esto:

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

el resultado es algo distinto de foo. No haga que.

Por lo general, esto les sucede a los usuarios de CSH, que omitieron proteger sus ~/.cshrc contra shells no interactivos. También podría sucederle a los usuarios de BASH que establecieron su BASH_ENV.

Answer 2

Cuando inicia gdb desde el shell, lo inicia como un nuevo proceso, no hay forma de evitarlo. En Unix, los nuevos procesos heredan parte del entorno del principal.

Para asegurarse de que una variable se hereda, si está utilizando un shell Bourne similar, tratar de exportarlo:

export LD_LIBRARY_PATH=... 

Answer 3

El depurador ( inferior en la jerga BGF) siempre se inicia con un limpio ambiente para obtener resultados más reproducibles. Para establecer una variable allí, utilice el comando

set env VARNAME=VALUE 

antes de ejecutar.

Answer 4

Me encuentro con el mismo problema. Me parece que en inferior.h (código fuente de GDB gdb/inferior.h) hay una macro STARTUP_WITH_SHELL, también hay un pedazo de comentario como

/* 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 

Entonces me puse STARTUP_WITH_SHELL como 0 y decrementa START_INFERIOR_TRAPS_EXPECTED y recompilado mi BGF . Después de eso, gdb ya no comenzó desde el caparazón.