mezos
Messages postés1Date d'inscriptionmercredi 31 octobre 2007StatutMembreDernière intervention31 octobre 2007 31 oct. 2007 à 15:11
Bonjour,
merci pour ce petit bout de soft très pratique.
meech
Messages postés209Date d'inscriptionvendredi 11 avril 2003StatutMembreDernière intervention14 août 2007 4 janv. 2005 à 01:21
Je te rassure, Nébula, "man ldd" ne donne pas plus sur ma Debian...
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 23 déc. 2004 à 17:36
J'ai vu que tu avais restructuré ton code, je préfère ainsi c'est beaucoup plus clair :)
Pour ce qui est des valeurs entre parenthèses je n'en ai aucune idée, man ldd ne donne pas d'explications (sur NetBSD en tout cas). Et je n'ai jamais utilisé Cygwin, donc...
Bonne continuation !
meech
Messages postés209Date d'inscriptionvendredi 11 avril 2003StatutMembreDernière intervention14 août 2007 23 déc. 2004 à 10:10
Deux remarques encore :
1. Réctificatif : ce n'est pas objdump qui s'inspire de ce code mais plutôt l'inverse ;-) [cf. mon minable commentaire du 22/12/2004 22:11:48].
2. Je ne crois pas que la commande objdump puisse spécifier si la dll est trouvée ou non dans le PATH de Windows.
Une question :
Quelqu'un sait-il à quoi correspond précisément l'adresse mémoire spécifiée entre paranthèses lors de l'exécution de ldd sous linux ? En effet, j'aimerais à l'avenir améliorer la correspondance entre la véritable commande ldd et ce code (je pense également au mode 'verbose' et aux relocations).
Nébula -> merci pour ta note ;-) sympa.
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 22 déc. 2004 à 23:07
A priori c'était bien cela, le programme tourne désormais convenablement. Je vais jeter un oeil du côté de Doxygen, je cherche justement de tels outils... Merci :)
meech
Messages postés209Date d'inscriptionvendredi 11 avril 2003StatutMembreDernière intervention14 août 2007 22 déc. 2004 à 22:23
Nébula,
Ne serait-ce pas par hasard la ligne 228, où l'allocation dynamique de mémoire est réalisée, qui serait en cause.
A priori, il faudra ajouter au vieux calcul 2 (en raison du caractère de fin de chaîne et du slash que j'ajoute par la suite).
Je viens de corriger cela, et au cas où tu as un peu de temps, fais-moi signe si ce code foire encore.
Encore merci ;-)
meech
Messages postés209Date d'inscriptionvendredi 11 avril 2003StatutMembreDernière intervention14 août 2007 22 déc. 2004 à 22:11
Bonjour Nébula,
1. Oui, je connais 'objdump' (lequel doit faire sensiblement la même chose). Du reste, je me suis basé sur les sorties de ce programme pour "valider" ce code.
2. Pour les commentaires, les "--- debut ---" et "--- fin ---" appartiennent bel et bien à une sale habitude. Toutefois, les commentaires directs des fonctions (du style @param) sont traités par l'outil libre Doxygen (ici j'ai utilisé ce qui est appelé le "Java-Style"). Ce n'est peut-être pas la référence, mais bon... désolé...
3. Comme tu le soulignes, les erreurs sont la preuve que ce dump n'est pas validé. Erreur de ma part donc... Pas de XP-SP2 chez moi, mais je fais au plus vite pour corriger cette grosse bévue.
En tout cas, merci de tes remarques particulièrement pertinente qui m'apprendront à vérifier avant de publier.
PS. Merci pour la sortie dbg.
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 22 déc. 2004 à 20:35
Hm je viens de tester le programme, et il plante systématiquement sur la deuxième DLL importée (testé le ldd.exe du zip et une version que j'ai recompilée, sur eux-même et sur notepad.exe). J'utilise MinGW et Windows XP SP2.
Voici la sortie de GDB pour t'aider à débugger :
(gdb) set args notepad.exe
(gdb) run
warning: HEAP[a.exe]:
warning: Heap block at 003D27F0 modified at 003D2818 past requested size of 20
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c911231 in _libmsvcrt_a_iname ()
(gdb) bt
#0 0x7c911231 in _libmsvcrt_a_iname ()
#1 0x7c97c943 in _libmsvcrt_a_iname ()
#2 0x7c96db9c in _libmsvcrt_a_iname ()
#3 0x7c97cd11 in _libmsvcrt_a_iname ()
#4 0x7c97df66 in _libmsvcrt_a_iname ()
#5 0x7c95a5d0 in _libmsvcrt_a_iname ()
#6 0x7c9368ad in _libmsvcrt_a_iname ()
#7 0x77bfc2de in _libmsvcrt_a_iname ()
#8 0x00401694 in DumpImportsSection (base=5111808, pNTHeader=0x4e00e0) at win32ldd.c:251
#9 0x004016ef in DumpExeFile (dosHeader=0x4e0000) at win32ldd.c:282
#10 0x00401841 in DumpFile (filename=0x3d24a8 "notepad.exe") at win32ldd.c:331
#11 0x00401a3f in main (argc=2, argv=0x3d2510) at win32ldd.c:422
(gdb)
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 22 déc. 2004 à 20:21
J'oubliais : le format de tes commentaires est une simple habitude, ou il fait partie d'un programme de documentation automatique (et si oui, pourrais-je connaître son nom) ?
cs_Nebula
Messages postés787Date d'inscriptionsamedi 8 juin 2002StatutMembreDernière intervention 7 juin 20072 22 déc. 2004 à 20:18
C'est intéressant, mais connais-tu objdump ? Il fait partie de la suite GCC et fait (entre autres) cette liste de librairies, pour la plupart (sinon tous) des formats exécutables gérés par GCC ;-)
31 oct. 2007 à 15:11
merci pour ce petit bout de soft très pratique.
4 janv. 2005 à 01:21
23 déc. 2004 à 17:36
Pour ce qui est des valeurs entre parenthèses je n'en ai aucune idée, man ldd ne donne pas d'explications (sur NetBSD en tout cas). Et je n'ai jamais utilisé Cygwin, donc...
Bonne continuation !
23 déc. 2004 à 10:10
1. Réctificatif : ce n'est pas objdump qui s'inspire de ce code mais plutôt l'inverse ;-) [cf. mon minable commentaire du 22/12/2004 22:11:48].
2. Je ne crois pas que la commande objdump puisse spécifier si la dll est trouvée ou non dans le PATH de Windows.
Une question :
Quelqu'un sait-il à quoi correspond précisément l'adresse mémoire spécifiée entre paranthèses lors de l'exécution de ldd sous linux ? En effet, j'aimerais à l'avenir améliorer la correspondance entre la véritable commande ldd et ce code (je pense également au mode 'verbose' et aux relocations).
Nébula -> merci pour ta note ;-) sympa.
22 déc. 2004 à 23:07
22 déc. 2004 à 22:23
Ne serait-ce pas par hasard la ligne 228, où l'allocation dynamique de mémoire est réalisée, qui serait en cause.
A priori, il faudra ajouter au vieux calcul 2 (en raison du caractère de fin de chaîne et du slash que j'ajoute par la suite).
Je viens de corriger cela, et au cas où tu as un peu de temps, fais-moi signe si ce code foire encore.
Encore merci ;-)
22 déc. 2004 à 22:11
1. Oui, je connais 'objdump' (lequel doit faire sensiblement la même chose). Du reste, je me suis basé sur les sorties de ce programme pour "valider" ce code.
2. Pour les commentaires, les "--- debut ---" et "--- fin ---" appartiennent bel et bien à une sale habitude. Toutefois, les commentaires directs des fonctions (du style @param) sont traités par l'outil libre Doxygen (ici j'ai utilisé ce qui est appelé le "Java-Style"). Ce n'est peut-être pas la référence, mais bon... désolé...
3. Comme tu le soulignes, les erreurs sont la preuve que ce dump n'est pas validé. Erreur de ma part donc... Pas de XP-SP2 chez moi, mais je fais au plus vite pour corriger cette grosse bévue.
En tout cas, merci de tes remarques particulièrement pertinente qui m'apprendront à vérifier avant de publier.
PS. Merci pour la sortie dbg.
22 déc. 2004 à 20:35
Voici la sortie de GDB pour t'aider à débugger :
(gdb) set args notepad.exe
(gdb) run
warning: HEAP[a.exe]:
warning: Heap block at 003D27F0 modified at 003D2818 past requested size of 20
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c911231 in _libmsvcrt_a_iname ()
(gdb) bt
#0 0x7c911231 in _libmsvcrt_a_iname ()
#1 0x7c97c943 in _libmsvcrt_a_iname ()
#2 0x7c96db9c in _libmsvcrt_a_iname ()
#3 0x7c97cd11 in _libmsvcrt_a_iname ()
#4 0x7c97df66 in _libmsvcrt_a_iname ()
#5 0x7c95a5d0 in _libmsvcrt_a_iname ()
#6 0x7c9368ad in _libmsvcrt_a_iname ()
#7 0x77bfc2de in _libmsvcrt_a_iname ()
#8 0x00401694 in DumpImportsSection (base=5111808, pNTHeader=0x4e00e0) at win32ldd.c:251
#9 0x004016ef in DumpExeFile (dosHeader=0x4e0000) at win32ldd.c:282
#10 0x00401841 in DumpFile (filename=0x3d24a8 "notepad.exe") at win32ldd.c:331
#11 0x00401a3f in main (argc=2, argv=0x3d2510) at win32ldd.c:422
(gdb)
22 déc. 2004 à 20:21
22 déc. 2004 à 20:18