Valeur de -Ttext dans un makefile

**jeroman** · 29/04/2021, 15h27

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.

**jeroman** · 29/04/2021, 20h33

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

. Et maintenant ça roule impec !

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

**Kannagi** · 29/04/2021, 23h01

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 :

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 .

**jeroman** · 30/04/2021, 05h48

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.

**jeroman** · 30/04/2021, 08h59

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 Makefile :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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...

**Kannagi** · 30/04/2021, 09h27

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.