[SOS] sos: au sujet de defauts d'initialisation

[Thomas Petazzoni]

Salut,

[ Mail du 17 novembre 2007... réaction le premier juin 2009. Je crois
  qu'on peut dire que ma réactivité est plus que moyenne. ]

Le Sat, 17 Nov 2007 20:07:03 +0100,
"guerineau" <chris.guer at wanadoo.fr> a écrit :

> A. Initialisation incorrecte de variables statiques:
> 
> ====================================================
> 
> Dans "certaines conditions" , certaines variables supposees
> initialisees ne le sont pas.
> 
> Exemple: 
> 
> - fs.c: fs_list

Ici, j'ai :

/** List of available filesystems registered in the system */
static struct sos_fs_manager_type * fs_list = NULL;

Donc a priori, pas de soucis pour celle-ci.

> - uaccess.c : __uaccess_zero_fool_gcc

Et :

int __uaccess_zero_fool_gcc = 0;

Bon, peut-être que ça a été changé depuis le message que tu as envoyé.

> l'outil "nm" renseigne que ces variables sont placees dans une
> section 'b'(ou 'B'), c'est a dire , non initialisee. Pour les
> variables ne faisant pas l'objet d'une initialisation a la
> declaration, ce placement ne semble pas aberrant. 

Effectivement. En C, les variables globales non-initialisées sont
placées dans une section ".bss". Cette section n'occupe pas de place
dans le fichier binaire résultant de l'édition de liens, mais le
chargeur du fichier binaire doit lors de l'exécution réserver
suffisamment de place pour cette section ".bss" et l'initialiser à zéro.

Par exemple, dans sos/fs.c, on a :

/** Last UID delivered for the FS instances */
static sos_ui64_t last_fs_instance_uid;

Si on regarde avec readelf :

$ readelf -s sos.elf | grep last_fs_instance_uid
422: 002a8030     8 OBJECT  LOCAL  DEFAULT    5 last_fs_instance_uid

Notre symbole est donc dans la section 5 (avant-dernier champ). Et la
section 5 correspond à :

$ readelf -S sos.elf|grep "\[ 5\]"
  [ 5] .bss              NOBITS          002a6d01 0a7d01 0982ff 00  WA  0   0 128


> En examinant de pres le comportement de gcc, on constate qu'il traite
> de maniere particuliere le placement des variables initialisees a
> zero: toutes les variables ainsi initialisee sont placees dans une
> section placee au dela de notre borne de chargement. En fait, dans
> une section ".bss". On peut alors conjecturer que GCC compte sur le
> runtime pour initialiser la zone .bss a zero.

Tout à fait. Et dans notre cas, c'est Grub qui est censé faire cette
initialisation.

Dans bootstrap/multiboot.S, le Multiboot header est défini comme suit :

multiboot_header:
  /* magic=        */ .long MULTIBOOT_HEADER_MAGIC
  /* flags=        */ .long MULTIBOOT_HEADER_FLAGS
  /* checksum=     */ .long -(MULTIBOOT_HEADER_MAGIC \
                              +MULTIBOOT_HEADER_FLAGS)
  /* header_addr=  */ .long multiboot_header
  /* load_addr=    */ .long __b_load
  /* load_end_addr=*/ .long __e_load
  /* bss_end_addr= */ .long __e_kernel
  /* entry_addr=   */ .long multiboot_entry

Donc le champ "bss_end_addr" du Multiboot header est défini à
__e_kernel. Cette variable est définie par le script d'édition de liens
sos.lds, et elle est bien déclarée *après* la section .bss.

La documentation de Grub indique bien (http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Header-address-fields) que la zone entre load_end_addr et bss_end_addr est remise à zéro :

bss_end_addr
    Contains the physical address of the end of the bss segment. The boot loader initializes this area to zero, and reserves the memory it occupies to avoid placing boot modules and other data relevant to the operating system in that area. If this field is zero, the boot loader assumes that no bss segment is present. 

À tout hasard, est-ce que tu utilises bien le boot par Grub, ou via le
petit bootloader que nous avons fourni ? En effet, il me semble bien
que ce dernier n'initialise pas le .bss comme le fait Grub, ce qui
pourrait expliquer les soucis que tu as rencontré.

Thomas
-- 
Thomas Petazzoni                         http://thomas.enix.org
Promouvoir et défendre le Logiciel Libre http://www.april.org
Logiciels Libres à Toulouse              http://www.toulibre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://the-doors.enix.org/pipermail/sos/attachments/20090601/88204131/attachment.pgp>