GDT Descripteur de segment de code & segment de données

Voila en ce moment j'étudie le code de Linux 0.01, mais j'ai problème dans la comprehésion du choix de la GDT.
La GDT de Linux est décrite comme ceci :

Code:

---

1 2 3 4 5 6

_gdt: .quad 0x0000000000000000 /* NULL descriptor */ .quad 0x00c09a00000007ff /* 8Mb */ .quad 0x00c09200000007ff /* 8Mb */ .quad 0x0000000000000000 /* TEMPORARY - don't use */ .fill 252,8,0 /* space for LDT's and TSS's etc */

---

Le premier est un descripteur NULL imposé par le processeur.
Celui qui suit est un descripteur de segment de code du noyau , le deuxième qui est presque identique est un descripteur de segment de données du noyau.
Si on regarde les valeurs de ses descripteurs, ils utilisent tout les deux la même zone mémoire physique. (Enfin ils "décrivent" la même zone mémoire physique...)
Et c'est la que ma question intervient :D

Quel est l'interet pour deux descripteurs comme ceci de décrire le même emplacement physique ?

Merci d'avance à ceux qui pourront me répondre :)

Citation:

---

Quel est l'interet pour deux descripteurs comme ceci de décrire le même emplacement physique ?

---

Be tu as toi meme répondu à ta question : il y en a un qui est un seg de code et l'autre de données :lol:

P e te demande-tu pourquoi on utilise pas un seul descripteur qui serait à la fois de code et de données ?
En fait le pmode est -comme son nom l'indique- un mode "protégé" car il classifie bcp les desc, il met en place une politique de rings de privilège, etc...
Donc avoir 2 desc -un de données et un de code- permet d'eviter, par exemple, qu'une appli ne puisse executer du code dans sa partie données, ou d'autres choses encore plus étranges ( :) )

Ok merci beaucoup en fait je me rends compte que je ne comprends pas réellement la différence entre un descripteur de code et de données.
Quelqun saurait m'expliquer ? :)
Merci d'avance.

Je me suis renseigné.
En fait un descripteur de code décrit la zone mémoire ou sera stocké les instructions du processus.
Et un descripteur de données décrira la zone mémoire ou sera stocké les variables et résultat de ce processus.
Mais je sais pas pourquoi j'ai l'impression que mélanger code et données ça donne un beau bordel dans une zone mémoire.
Je me demande comment le processeur arrive à utiliser ce mélange :?
Maintenant si ce qui précède est vrai, quand on lance un processus utilisateur par exemple, il possèdera un descripteur de données et de code lui aussi.
Si on relance exactement un nouveau processus identique, la logique de l'optimisation voudrait qu'on lui attribut le même descripteur de code que l'autre processus. On gagne donc de la place en mémoire.
Par contre ce nouveau processus n'aura pas forcément le même descripteur de données ? (car résultat différent).
Tout cela dire pour dire que, un processus ne devra pas avoir son segment de code et de données qui se chevauchent alors ?
Car si c'est le cas, le nouveau processus identique se verra attribuer le segment de code de l'autre donc forcément celui de donné car ils se chevauchent. Bref c est un peu le bordel encore dans ma tête je crois.
J'espère que quelqun aura compris ce que j'ai voulu dire et saura m'éclairer :)
Merci.

Plusieurs segments peuvent se chevaucher en mode protégé, l'intérêt c'est que les deux descripteurs n'autorisent pas les mêmes opérations. Le descripteur de code permet d'executer du code (et éventuellement de lire en mémoire) alors que le descripteur de données permet de lire et d'écrire. En faisant un segment de code et un de données qui pointent au même endroit, le kernel a son repaire, dans lequel il peut faire tout ce qu'il veut.

Merci beaucoup, ça commence à devenir clair.
Donc le fait que 2 segments (données et codes) se chevauchent n'est valable logiquement que pour un kernel alors ? Cette méthode n'aurai pas de sens dans le cas de processus utilisateur ?

Citation:

---

Cette méthode n'aurai pas de sens dans le cas de processus utilisateur ?

---

Mais si !! (sauf si tu veux faire un programme utilisateur sans pile :lol: )
Dans un programme utilisateur, tu auras (en général) deux ou trois descripteurs (sans compter le tss) qui définirons les 4Go de la RAM
Tout les process disposent de 4Go. Ce miracle est possible grâce au paging :wink:

Mettons le TSS de cote.
2 segments pour un processus ok je comprends, mais pourquoi on pourrait en avoir 3 ?

Citation:

---

2 segments pour un processus ok je comprends, mais pourquoi on pourrait en avoir 3 ?

---

-data
-code
-stack

C ce que g fais pour la gestion des processus dans mon os (dans une ldt)

:wink:

Ok, je vois :)
Alors comment se fait t il que sous Linux 0.01, il n'y a pas de segment de stack pour le noyau ?
Ou alors j'ai raté un épisode.

Il utilise sûrement le descripteur de donnée pour ss. Ce qui en théorie autorise la pile à grossir en écrasant des données ou du code, mais c'est le noyau, il sait ce qu'il fait ;)

Ok compris.
Putain les gars vous m'avez vraiment bien éclairé merci beaucoup !

J'ai une dernière question :mrgreen:
Lorsque que l'on fait un :

Code:

---

lgdtl <registre_gdt>

---

Ou dois je stocker physiquement la GDT ? (quelle adresse je met dans le registre ?)
Je me demandais si il fallait donner une adresse qui était recouverte par un segment particulier ou non.
bref si quelqun avait des infos ce serait génial ;)
Merci.

C'est pas lgdtl c'est lgdt ;)
Ben en fait comme c'est la gdt qui contient les infos des segments, l'adresse que tu mets c'est une adresse linéaire, qui ne s'appuie sur aucun segment.

ok merci ;)

Je v te mettre un bout de code, tu comprendras mieux:

Code:

---

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

; code : ... lgdt [GDT.Ptr] ... ; passe en pmode ...     ; data : GDT.Ptr: .limite: dw 8192 ;limite de la GDT dans la mem (inferieur/egal à 8192) ; en gros c'est la taille de la GDT quoi... .base: dd GDT.MaGdtDeTest ; Adresse _physique_ où commence la GDT   ; LA, tu as ta GDT GDT.MaGdtDeTest dd 0,0,0,0 ; Rien du tout, desc 0 times (8192-16) db 0

---

Et puis c'est lgdt en effet (dans la syntaxe AT&T en tout cas)