Discussion :

[Bktero]

Bonjour,

J'ai un script bash qui fait ceci :

#!/bin/bash
nohup mspdebug rf2500 gdb &
msp430-gdb a.out --command=command.gdb

La première commande lance un GDB proxy (équivalent à un GDB serveur ?), la second lance un GDB qui se connecte au proxy pour débogguer la cible (qui est une carte électronique avec un MCU : http://www.ti.com/tool/msp-exp430g2). Mon script GDB lance l'exécute du programme et je dois faire Ctrl+C pour mettre en pause.

Si je lance ces 2 commandes séparément et manuellement depuis mon terminal, c'est OK. En revanche, en lançant ces commandes via ce script bash, le Crtl+C termine le script au lieu de mettre mon programme en pause, c'est pas OK !

Ma question est donc : comment rediriger Ctrtl+C vers le GDB lancé par le script ?

Merci d'avance !

[Jipété]

https://www.cyberciti.biz/faq/unix-l...able-controlc/
et avec un exemple :
http://www.unix.com/shell-programmin...ll-script.html

[jack-ft]

Hum...

Si j'ai bien compris, Bktero ne veut pas que le script ignore le ctrl-c (signal SIGINT = 2), mais plutôt le transmettre au programme lancé par le script.

Je ne suis pas un expert de ce genre de truc, mais il me semble qu'il faudrait plutôt faire quelque chose comme ceci (non testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash
 
# trap ctrl-c and call the ctrl_c function
trap ctrl_c INT
 
# This is what should be done when ctrl-c occurs
function ctrl_c() {
    echo "** Trapped CTRL-C"
    kill -SIGINT ${gdb_pid}
}
 
nohup mspdebug rf2500 gdb &
 
msp430-gdb a.out --command=command.gdb &
 
# Get the pid of the last background process (the gdb process)
gdb_pid=$!
 
# Wait for children to finish
wait

[Jipété]

Hum...

Si j'ai bien compris, Bktero ne veut pas que le script ignore le ctrl-c (signal SIGINT = 2), mais plutôt le transmettre au programme lancé par le script.

Oh lala oui, je suis confus, j'ai lu trop vite, vraiment désolé et merci de corriger mes erreurs/horreurs, où y-aurait-il un trou de souris pour que j'aille m'y cacher ?

Vraiment vraiment désolé,

[Sve@r]

Je ne suis pas un expert de ce genre de truc, mais il me semble qu'il faudrait plutôt faire quelque chose comme ceci (non testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash
 
# trap ctrl-c and call the ctrl_c function
trap ctrl_c INT
 
# This is what should be done when ctrl-c occurs
function ctrl_c() {
    echo "** Trapped CTRL-C"
    kill -SIGINT ${gdb_pid}
}
 
nohup mspdebug rf2500 gdb &
 
msp430-gdb a.out --command=command.gdb &
 
# Get the pid of the last background process (the gdb process)
gdb_pid=$!
 
# Wait for children to finish
wait

Bonjour

Super exemple (surtout pour un non-expert). Malheureusement ça ne fonctionne pas (mais ce n'est pas de ta faute car tout est nickel).

Donc moi j'ai testé parce que ça me plaisait et que je voulais le voir tourner. Voici ce que j'ai écrit

Programme "fils.sh"

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash
 
ctrl() {
	echo fils ok
}
 
trap ctrl 2
 
echo "Je suis le fils pid=$$"
i=0
while test $i -lt ${1:-20}; do
	i=$(($i + 1))
	echo "i=$i (pid=$$)"
	sleep 1
done

Jusque là pas de souci. Je lance ./fils.sh et je peux taper à loisir "ctrl-c" dans ma console, je vois bien le "fils ok" apparaitre à chaque fois. Puis au bout de 20 itérations le fils s'arrête.

Maintenant je veux lancer le fils avec ta méthode. J'écris donc le code suivant

Programme "pere.sh"

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash
 
ctrl() {
	echo "pere ok (fils=$pp)"
	kill -2 $pp
}
 
trap ctrl 2
 
echo "Je suis le père pid=$$"
 
./fils.sh 100 &
pp=$!
echo "pid fils=$pp"
wait

Ben là ça ne fonctionne pas. Je veux dire que si je lance le père, je vois bien le pid du fils mais déjà le "ctrl-c" ne fonctionne qu'une seule fois (je ne vois qu'une fois apparaitre "pere ok (fils=xxxx)". Ensuite, plus rien toutefois le fils continue à afficher son compteur. Et en faisant un ps je vois que le père a disparu (le fils est rattaché au init). A ce niveau, je me dis que comme ça fonctionne avec le fils et sa boucle mais pas avec le père et son wait, je remplace alors le père par ceci:

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/bin/bash
 
ctrl() {
	echo "pere ok (fils=$pp)"
	kill -2 $pp
}
 
trap ctrl 2
 
echo "Je suis le père pid=$$"
 
./fils.sh 100 &
pp=$!
echo "pid fils=$pp"
while ps -fu $LOGNAME |awk '{print $2}' |grep "$pp" 1>/dev/null; do
	sleep 5
done
wait
echo "fils terminé"

Là, le père reste en vie quand je tape "ctrl-c" mais je ne vois pas apparaitre le message correspondant au "ctrl-c" (kill -2) dans le fils. Toutefois le kill part bien car si je tape "ctrl-c" quand le fils a fini mais pendant que le père est encore dans son sleep 5 je vois un message type "kill (xxxx): aucun processus de ce type". Donc le kill part bien mais il ne semble pas reçu par le fils. Vérifions cette hypothèse avec ce fils

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
echo "Je suis le fils pid=$$"
i=0
while test $i -lt ${1:-20}; do
	i=$(($i + 1))
	echo "i=$i (pid=$$)"
	sleep 1
done

Effectivement là le fils ne se protège contre rien. Toutefois il ne s'arrête pas quand le père lui envoie un kill -2.

A ce niveau là je reste sec. Pourtant ton exemple initial était exemplaire et correspondait bien à ce qui est écrit concernant trap et kill. Je pense que c'est à cause du trap du père qui inhibe le trap du fils...

Désolé Bktero, je ne vois pas comment résoudre ton souci...

[Bktero]

J'ai tenté de mettre un place l'astuce de jack-ft mais sans succès

Voici mon script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
 
# Trap SIGINT (CTRL+C) to avoid stopping the script and redirect it to GDB
trap ctrl_c INT
 
function ctrl_c() {
    echo "** Trapped CTRL+C, redirecting it to ${pid_gdb}"
    killall -INT ${pid_gdb}	
}
 
# Run mspdebug as GDB proxy
mspdebug rf2500 gdb 1>/dev/null 2>&1 &
 
pid_mspdebug=$!
echo "mspdebug is running with PID ${pid_mspdebug}"
 
# Run GDB
msp430-gdb a.out --command=command.gdb --quiet
pid_gdb=$!
echo "gdb is running with PID ${pid_gdb}"
 
# Wait for GDB completion
wait ${pid_gdb}
echo "dgb has ended, waiting for mspdebug..."
wait ${pid_mspdebug}
echo "mspdebug has ended, script exits"

Quand je lance ce script depuis un premier terminal, la session de debug se lance. Depuis un second terminal, je fais killall msp430-gdb -INT et le GDB se met correctement en pause. En revanche, si je fais un CRTL+C depuis le premier terminal, voici ce qui se passe :

$./debug.bash

mspdebug is running with PID 7396
Reading symbols from /home/pgradot/Documents/GitHub/Planteur/launchpad/a.out...done.
_reset_vector__ () at /build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S:105
105	/build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S: No such file or directory.
	in /build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S
Breakpoint 1 at 0xfb08
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
Remote connection closed
thread.c:79: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
thread.c:79: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
** Trapped CTRL+C, redirecting it to 
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
./debug.bash: line 18:  7397 Aborted                 (core dumped) msp430-gdb a.out --command=command.gdb --quiet
gdb is running with PID 7396
dgb has ended, waiting for mspdebug...
mspdebug has ended, script exits

Je ne sais pas si c'est un problème de ce portage de gdb ou un problème de mon script... Des idées ?

[disedorgue]

Bonjour,

Peut-être que la solution suivante fonctionnerait (pas testé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#!/bin/bash
nohup mspdebug rf2500 gdb &
sleep 1
exec msp430-gdb a.out --command=command.gdb

Le sleep est là juste pour temporiser histoire d'attendre que le chargement du contexte de la commande nohup... soit au moins initiée avant de lancer la commande exec qui écrasera le contexte du script bash pour le remplacer par celui de la commande msp430-gdb