[SOS] Bug supposé a l'initialisation de la GDT.

[David Decotigny]

Bonjour,

romain a écrit :
> 1/ Dans la macro BUILD_GDTE on n'affecte pas les bits de la base 31 à 34
> (sos_ui8_t  base_paged_addr_31_24;)
> #define BUILD_GDTE(descr_privilege_level,is_code) ...
> (Coup de bol que la base soit à 0 ;), ce doit etre un oublie )

C'est un oubli en effet.

Effectivement, on a du bol, mais pas tant que ça. Car cette macro est
utilisee pour une initialisation statique (ie dans le binaire) par le
compilo, donc ca se passe bien. Car gcc met des 0 par defaut dans ce
qu'il cree dans le binaire.

Cette remarque est en pratique valable pour gcc et seulement pour des
allocations style "int t[15] = { 0, 1, 2 };" (allocation dans des
sections genre .data ou .rodata) : le binaire sera reellement rempli
avec 1, 2, 3 puis 12 zeros derriere (merci gcc). Elle n'est pas toujours
valable avec des allocations du style "int t[15];". (allocation dans le
.bss). Dans le 2eme cas, la taille est en realite nulle dans le binaire,
il y aura reservation de place en RAM (ou en VM) au chargement du
binaire seulement => le contenu de 't' dependra du contenu en RAM au
moment du chargement ou du demand mapping. Ca me fait penser que ca
serait bien de mettre le bss du noyau a zero au debut du lancement du
noyau (je pense que Grub s'en charge, mais pas le bootsecteur de sos)...

> 2/la strucutre x86_gdt_register bizarement dimensionnée !
>  
> struct x86_gdt_register {
>   sos_ui16_t  limit;
>   sos_ui32_t base_addr;
> } __attribute__((packed, aligned(8)));
>  
> 16 + 32 = 48 soit 6 octets a passer au processeur (spec intel ) !
> Ici elle est aligné sur 8, si je ne m'abuse, cela indique que gcc place
> cette structure sur 8 octets (modulo 8 octets pour l'optimisation...).

Oui, mais comme dit Christophe, c'est la spec Intel qui le conseille.

> du coup il y'a 2 octets en rab ! il vont ou ? enfin comment le

Oui mais on n'a pas le choix : on prefere perdre 2 octets dans le
binaire que d'avoir une penalite a payer a l'execution. LA solution
serait d'ecrire tout ça en assembleur.

> à premiere vu je dirais que le pad est mis a la fin (si non sos ne

Oui, rassure-toi, ce padding sera toujours mis a la fin. Autrement dit
le processeur ne le verra pas puisque seuls les 6 premiers octets
l'interessent.

Bonne soiree,