Discussion :

[jeroman]

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]

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]

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]

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]

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]

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.

[Christophe]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

-Wl,--oformat=binary

-wl permet de passer directement des options au linker.