Valeur de -Ttext dans un makefile

Bonjour,

Je lis actuellement l'excellent tuto de Michelizza, mais je rencontre des problèmes chez moi. Notamment cette partie : https://michelizza.developpez.com/re...e-systeme/#LVI

J'ai simplement la ligne "kernel : loading new gdt..." qui défile à l'infini et de temps en temps le bootloader qui se relance... Manifestement, il y a un soucis. Est-ce que cela fonctionne chez vous ? Comment faire fonctionner cet exemple ?

J'utilise QEmu. (Je ne suis pas à l'aise avec Bochs, trop relou à paramétrer)

J'ai légèrement modifié les Makefile afin de supprimer quelques erreurs. (Je ne sais pas si c'est la cause)

Une piste ?

Merci par avance.

Bon, je me réponds à moi-même. J'ai ENFIN trouvé la source du problème, complètement par hasard.

Y avait un problème dans un Makefile. J'ai remplacé

Code:

---

ld -melf_i386 -Ttext 1000 $^ -o $@

---

par

Code:

---

ld -melf_i386 -Ttext 2000 $^ -o $@

---

. Et maintenant ça roule impec ! :P

Maintenant, reste à savoir pourquoi ça coinçait...

Ttext est une option du compilo pour indiquer où se trouve le code en memory map (en gros pour que les call/label n'ont pas une adresse faussé)
La bonne adresse doit être 0x1000 si j'ai bien compris :
https://michelizza.developpez.com/re...oot_kernel.png

Mais d’après OS Dev on peut mettre du code à 0x500 :
https://wiki.osdev.org/Memory_Map_(x86)

Et si ça marchais pas à 1000 , c'est que 1000 en hexa fait 0x3E8 , qui correspond aux table d’interruption et aux BIOS :)
A 2000 tu es à 0x7D0 donc un espace libre .

C'est bizarre, cette histoire ! Quelle pourrait donc être l'origine du problème ?

D'après la doc de l'outil ld, Ttext est toujours en hexa. Donc le "0x" est facultatif.

Avec 500 ou 1000 ça marche pas chez moi.

J'ai sorti le fichier lié en assembleur, et effectivement il y avait un gros problème. En fait, le fichier sorti était en format ELF. Ca pouvait pas marcher puisqu'il fallait du binaire.

Voici le makefile, que j'ai modifié et qui fonctionne maintenant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

OBJ=kernel CC=gcc -Wall -m32   all: $(OBJ)   kernel.elf: kernel.o screen.o lib.o gdt.o idt.o interrupt.o int.o pic.o ld -melf_i386 -o $@ -Ttext 1000 $^   kernel: kernel.elf objcopy -O binary kernel.elf kernel.bin   int.o: int.asm nasm -f elf32 -o $@ $^   .o: .c $(CC) -c $^   clean: rm -f $(OBJ) *.o *.elf

---

A l'origine, le "ld" avait bien l'option "--oformat binary", mais cela me générait plein d'erreurs ! (liées à la __GLOBAL_OFFSET_TABLE__ ) D'où la modif que j'avais effectuée et qui ne marchait pas bien du coup. C'est peut-être pour ça qu'avec l'adresse 0x2000 ça fonctionnait, mais ce n'était que pur hasard je suppose :aie:

Est-ce qu'il y a moyen de générer du binaire depuis "ld" directement, sans passer par "objcopy", sans que cela me génère un paquet d'erreurs ? Bon après, c'est peut-être pas super indispensable... Si ça marche comme ça... 8-)

GCC fournit du .elf par défaut , du coup , étonnant que cela marche...
(mais il y'a des chances qu'il exécute du code "aléatoire" , vu que l'entete du .elf est exécuter...)
Sinon tu peux remettre "-oformat binary" sur ld , et donc il fournit le binaire , objcopy doit sûrement faire une simple copy.

Je n'utilise jamais objcopy pour la sortie des binaire seulement ld.

Citation:

---

Est-ce qu'il y a moyen de générer du binaire depuis "ld" directement, sans passer par "objcopy", sans que cela me génère un paquet d'erreurs ?

---

Regarder du coté de l’option gcc :

Code:

---

-Wl,--oformat=binary

---

-wl permet de passer directement des options au linker.