Pourquoi GDB lance-t-il un nouveau shell et comment désactiver ce comportement?

Je cherchais un problème où le démarrage de l’application à partir de GDB entraîne une erreur de recherche de symbole, mais que le démarrage à partir du shell fonctionne.

Il s’avère que chaque fois que vous démarrez un programme à partir de GDB, un nouveau shell est créé et donc, toutes les variables d’environnement que j’avais définies avant de démarrer GDB (comme LD_LIBRARY_PATH ).

Ce n’est pas vraiment le comportement que je veux. Quelqu’un peut-il expliquer la raison derrière cela, ou me dire comment je peux le désactiver?

Je suppose que vous définissez inconditionnellement LD_LIBRARY_PATH dans votre ~/.cshrc ou similaire. Donc, si à partir d’un shell, vous faites ceci:

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

le résultat est autre chose que foo . Ne fais pas ça .

Cela arrive généralement aux utilisateurs de CSH, qui ont négligé de protéger leur ~/.cshrc contre les shells non interactifs. Cela pourrait également arriver aux utilisateurs BASH qui définissent leur BASH_ENV .

Je rencontre le même problème. Je trouve que dans inferior.h (code source de gdb gdb / inferior.h ), il existe une macro STARTUP_WITH_SHELL , il y a également un commentaire

 /* 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. Eg, (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 

Ensuite, j’ai défini STARTUP_WITH_SHELL sur 0 et décrémenté START_INFERIOR_TRAPS_EXPECTED et recompilé mon gdb. Après que gdb ne soit plus parti de shell.

Lorsque vous démarrez gdb à partir du shell, vous le démarrez en tant que nouveau processus, il n’y a aucune solution. Sous Unix, les nouveaux processus héritent d’une partie de l’environnement du parent.

Pour vous assurer qu’une variable est héritée, si vous utilisez un shell de type bourne, essayez de l’exporter:

 export LD_LIBRARY_PATH=... 

Le débogage ( inférieur dans le jargon gdb) est toujours lancé avec un environnement propre afin d’obtenir des résultats plus reproductibles. Pour y définir une variable, utilisez le

 set env VARNAME=VALUE 

commande avant de courir.