Merzhin79
Messages postés3Date d'inscriptionmercredi 21 juillet 2004StatutMembreDernière intervention30 juillet 2005
-
9 juil. 2005 à 13:25
Merzhin79
Messages postés3Date d'inscriptionmercredi 21 juillet 2004StatutMembreDernière intervention30 juillet 2005
-
30 juil. 2005 à 17:45
ALors c'est assez compliqué alors je vais expliquer ca point par point :
1-j'ai un bootsect en assembleur qui reste en mode reel, qui charge un programme a l'adresse 100:0 et qui le lance.
2-Le programme charger reinitialisise ces segments de données ect.. puis j'apelle un procedure que j'ai ecrite en C qui se nomme "principal".
3-Cette procedure ecrite en C va appeler une fonction par exemple "void test(void)" qui ne fait rien. Quand je debug sous BOCHS, pas de probleme, on voit bien les deux CALL passer (principal + test).
4-Je modifie la fonction test pour prendre un argument (par exemple un int) et je relance le debug sous BOCHS. Le premier CALL a la premiere fonction en C (principal) marche, ensuite il me met n'importe quoi (j'ai pas chercher a savoir ce qu'il faisait exactement) puis il fait un rtn. Bref il a pas fait le CALL de ma deuxieme fonction "test".
Et cela se produit seulement quand je rajoute un argument dans la focntion "test". Je pense avoir un probleme de compilation ou peut etre de lien (j'avoue etre perdue la).
Voila la ligne pour la compilation : gcc -c kernel.c
Je signale aussi que je reste en permanence en mode reel.
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 9 juil. 2005 à 14:35
Salut,
Un bon debugger doit faire l'affaire,mais il faudrait quand même préciser si c'est du 16 ou du 32 bits.De l'assembleur ou du mitigé assembleur C,inline pas inline etc .....
ToutEnMasm
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 10 juil. 2005 à 19:37
Salut,
C'est déja plus précis,je suspecte des conventions d'appels non respectés.Un appel a une fonction C ne s'écrit pas comme un appel a une fonction asm.Un appel long ne se code pas comme un appel court avec retn.
Pour savoir si le stack Frame (encadrement de la pile en bon franchouillard) est correct frapper ces mots dans MSDN et sa vous ménera directement aux conventions d'appels par proc.Chaque proc est construit suivant un modèle de gestion de la pile qui lui est propre et avec d'autres particularités.
Soit l'assembleur fait le travail et on est bien content de ne pas avoir a régler ce genre de détails,soit on essaye de construire soit même un stack frame avec les instructions leave et ret N , mais c'est du bricolage.
Masm résoud le problème avec l'instruction proc (construction du Stack frame) et proto (pour la convention d'appel).La convention d'appel peut être standard ou C.
Dans quels cas vous placer vous ?.
ToutEnMasm
Merzhin79
Messages postés3Date d'inscriptionmercredi 21 juillet 2004StatutMembreDernière intervention30 juillet 2005 30 juil. 2005 à 17:45
J'ai compris c'est que comme je l'indiquer je suis en mode reel (donc 16 bit) hors GCC est un compilateur 32 bits (donc non compatible avec le mode reel et c'est pourquoi cela marche en mode proteger).
Pour forcer GCC a compiler en 16 bit, il suffit de rajouter l'instruction asm .code16 dans le code.