Reprise du message précédent :
Je ne vois pas ce que tu peux de faire plus dans ce fichier (à part faire des write directe au lieu de sprintf et concatenation) mais tu risque de sérieusement dégradé les performances
 
question: Que fait le main? Combien de RAM utilise-t-il? Peux-tu l'optimiser? Tu peux utiliser des outils comme gprof et gcov et biensur gdb/ddd pour regarder la mémoire, les appels aux fonctions, etc.

 
Pour le main c'est assez compliqué à expliquer mais je ne peut pas le publier ici. En quelque sorte c'est un programme qui fait des lecture et ecriture  sur le port série afin de communiquer avec une carte électronique dans laquel il y a des macro et sur laquel se touve un ecran LCD et un lecteur d ecarte à puce.
 
Alors gprof/gcov je connaissais pas et pour gdb/ddd je connais. En fait moi je développe sous Kdevellop donc je peut débuguer avec gdb. Mais pour la cible je compile en ligne de commande avec mon compilateur croisé puis je partage mon binaire via NFS sur la cible pour le tester sur celle-ci. Par contre je n'arrive pas à débuguer sur la cible c'est ca le hic. J'ai essayer avec gdb server sur la cible et un gdb arm sur l'hote mais j'arrive pas a mettre d epoint d'arret et compagnie.
 
Par contre si quelque peut m'expliquer comment connaitre l'etat de ma pile sous KDevelop, je suis prenneur.

Bon alors j'ai refait une nouvelle version du fichier, ou j'ai cette fois enlever énormement de chose qui ne me server finalement pas dans ce code. Par exemple la possibilité d epasser de options verbose, cookies, referer,...  l'encoage 64 qui me servait que a un cas particulier.
 
J'ai également compacter les 3 fonctions post, postURL, postURLbyParts en une seul fonctions qui est post.
 
Le fichier est donc bcp plus light.
 
Nouveau fichier
 
Comme d'habitude ca marche sur la machine d edéveloppement mais pas sur ma cible.
 
Apparement ca plante au niveau du socket dans la fonction open_client_socket et plus précisement sur le gethostbyname.
 
Petitte précision la fonction gethostbyname, marche très bien dans d'autre programme.
 
Voilà je compte pour vous pour critiquer ce nouveau fichier et trouver l'erreur. ca serait le bonheur.
 
Aller merci d'avance !

Nous avons besoin de savoir exactement le probleme et pas un

Tu disais que tu as réussi à faire marcher gdb.server sur la cible mais que tu ne pouvais pas mettre des points d'arrêts, etc. Peux-tu nous donner la trace gdb (le retour de la commande where par exemple) du problème?

 
 
Très bien alors voici la démarche sue j'emploi :
 
1: Je lance la compile avec mon compilateur croisé et j'obtiens 2 fichiers : appli et appli.gdb
2: Je met appli sur ma cible
3: je lance gdbserveur sur la cible  

4: je lance mon arm-elf-gdb sur la machine hote

gdbinit_lxnet50 est un fichier texte qui indique les coordonées de la cible :

5 : A partir de la liaison entre la cible et la machine hote (Pc de developpement) est effectuée et je peut lancer le programme avec run.
 
En résumé ca donne çà:
 
Côté cible :

 
côté hote :

 
Par contre je n'arrive pas mettre de point d'arrêt, donc pour l'instant gdb me sert à rien puisque j'arrive uniquement a lancer le prog avec la command run mais c'est comme si je le lancer sans gdb car je met pas d epoints d'arrêts.
 
J'ai essayer ca :

les lancements de gdbserver et de arm-gdb sont OK.
Tu dis que le programme plante a priori à l'appel 'gethostbyname'... quelle est l'erreur? à ce moment, quel est le retour de la commande where?

 
Alors il y a pas d'erreur en fit le programme reste bloqué sur 'gethostbyname', comme si il était un boucle infinni, d'ailleurs la led d'emission de la carte reste allumé tant qu eje ne fé pas "ctrl+c". Je soupsonne mon socket de chercher indéfiniment. Je comprend pas.
 
Pour le where je vois pas trop ce qu etu veu dire. Comment j'utilise ca, je vois pas ? une fois que j'ai lancer le run il execute le prog sans s'arreter.

blocage à gethostbyname signifie que le programme n'arrive pas resoudre le nom...
essaye d'utiliser wireshark (nouveau nom d'Ethereal) et de regarder ce que la carte envoi sur le réseau... Et jusqu'à où vont les packets.

 
Ca y est j'ai régler le problème du gethostbyname, j'ai remplie moi même la structure puisque finalement j'ai les données nécessaire, IP, famille=AF_INET, longueur=4 et voilà ca larche. Mais merci tout de même.
 
Mon programme tourne enfin sur ma cible, mais n'est pas encore parfait, il faut maintenant que je le modifie de façon a ce qu'il respecte un peu mieux les règles de l'embarqué, de plus je doit en faire un daemon.  
 
par contre je suis toujours interessé pour faire fonctionner mon débugger si quelqu'un a une idée?

je ne sais plus (la dernière fois que j'ai utilisé gdbserver, c'était il y a plus 2.5 ans sur une board SH4)... Essaye de jouer avec TCP et tty

Bonjour la portabilité!

 
J'utilise gdbserver via TCP avec telnet, je n'ai pas tester sur le port série car il me faut une sonde supplémentaire qu'il ne m'a pas été fourni avec le kit de véveloppement. De toute façon je préfère prendre la main par TCP.
 

 
C'est net, je suis d'accord !

Voici mon avancement :
 
Mon fichier final
 
Ce fichier est celui que j'ai inclus dans le daemon linux de mon module emvarqué.
 
Vous remarquerai j'ai mis des ifdef DEBUG à plusieurs endroit.
 
Lorsque je fais un define DEBUG cela veut dire que je n'utilise pas le programme en tant qu edaemon sur mon module embarqué, mais que je le lance en debug sur ma machine de développement. J'ai essayé avec ce define de gerer les différentes erreurs, afin qu'elle n'arette pas le programme mais plutôt pour qu'on retourne proprement dans la boucle infini du main.
 
Faites moi par de vos suggestions sur le fichier tel qu'il est maintenant. Si il y a encore du travail ou si cela parait bien.
 
Merci d'avance!