gdb et arguments multilignes

Bonjour, bonsoir

Je voudrais debogger mon programme qui, comme cela est explicité dans le titre, prend un argument de plusieurs lignes. Il s'agit en fait d'une chaîne d' hexa, genre \x01\x41\xff ect...
Je ne sais pas pourquoi mais il doit y avoir \r ou \n ou les deux dans le lot.
Résultat: l'argument que j'obtiens par ailleurs s'affiche sur plusieurs lignes dans le shell.

J'ai essayé les démarches suivantes:

Code:

---

1 2	gdb monprog.c (gdb) r copier/coller de la chaîne que j'ai affiché dans un autre bash

---

puis

Code:

---

gdb --args monprog $(prog2)

---

La sortie de prog 2 est l'argument de monprog bien thur.
Il se passe que je trouve des intrus dans argv[1] par la suite. En effet, pas mal de \x20 (espace si je ne m'abuse) se sont incrustés.

Je ne renacle pas à utiliser python ou bash.
Cependant je dois dire je n'ai pas accès au paramètre --with-python dans gdb au cas
où ce serait utile.

Exemple de sortie de prog2 (j'ai mis des \r et \n exprès):

Code:

---

1 2 3 4

#!/usr/bin/env python   buffer = "\xbf\xff\xfe\x33\x0atoto\x0dtiti\x0d\x0atutu" print buffer

---

Merci pour avoir lu jusqu'ici.
Merci pour vos réponses aussi :)

Hello,

Sous gdb, la commande « r » ou « run » s'utilise de la même façon qu'en shell : tu peux utiliser les apostrophes « ' » ou les guillemets « " » pour encadrer une chaîne contenant des espaces ou des caractères spéciaux, et il faut utiliser un anti-slash « \ » comme caractère de fin de ligne (sans espace ni blanc après) pour poursuivre à la suivante et considérer le tout comme une seule et unique chaîne.

Salut Obsidian,

Ca marche en effet, cela dit j'ai oublié de dire que j'ai à faire à des chaînes bien plus longues. S'il existe un autre moyen...

J'ai essayé les tuyaux, ça ne fonctionne pas (BROKEN PIPE).

Enfin s'il existe une solution miracle...

Tu peux aussi utiliser le résultat d'une commande, comme en shell, avec les symboles « ` » ou « $(…) », et encadrer ces symboles avec des guillemets « " » pour être sûr que le résultat sera considéré comme une chaîne unique. Du coup, tu peux mettre ta chaîne dans un fichier et l'insérer en argument pendant une session gdb avec :

Code:

---

(gdb) r programme "$(cat fichier.txt)"

---

Seulement, passer des arguments kilométriques de cette manière à un programme, c'est particulièrement sale ! Il est même probable que les arguments eux-mêmes ne soient pas conçus pour admettre des chaînes aussi longues.

Si ce que tu passes en argument, ce sont justement les données à traiter, alors la manière normale de procéder est de passer par l'entrée standard. Ça se gère comme un fichier, tu reçois le signal EOF lorsque la fin des données est atteinte, et tu n'as pas besoin de t'occuper de l'ouverture et de la re-fermeture. Ça permet également à l'utilisateur de piper ta commande avec une autre ou de passer directement le fichier en question à l'entrée standard avec « < ».

Citation:

---

J'ai essayé les tuyaux, ça ne fonctionne pas (BROKEN PIPE).

---

A priori, tu n'as pas besoin d'ouvrir explicitement un tube pour ce faire. Si tu as obtenu ce message en exploitant l'entrée standard, c'est probablement parce qu'il a été émis par l'autre programme qui, lui, s'est retrouvé confronté à un tube vide quand il cherchait à ÉCRIRE dedans. Fort probablement parce que ton programme s'est terminé avant d'avoir lu tout ce qu'il y avait à lire.