[GCC][WIN32][DEV-C++] COMMANDE LDD SOUS WIN32/PE - VERSION 0.2.0 BUILD 4 (MISE À
cs_Nebula
Messages postés
787
Date d'inscription
samedi 8 juin 2002
Statut
Membre
Dernière intervention
7 juin 2007
-
22 déc. 2004 à 20:18
mezos Messages postés 1 Date d'inscription mercredi 31 octobre 2007 Statut Membre Dernière intervention 31 octobre 2007 - 31 oct. 2007 à 15:11
mezos Messages postés 1 Date d'inscription mercredi 31 octobre 2007 Statut Membre Dernière intervention 31 octobre 2007 - 31 oct. 2007 à 15:11
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/28340-gcc-win32-dev-c-commande-ldd-sous-win32-pe-version-0-2-0-build-4-mise-a-jour
https://codes-sources.commentcamarche.net/source/28340-gcc-win32-dev-c-commande-ldd-sous-win32-pe-version-0-2-0-build-4-mise-a-jour
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