Sections BSS en _nostub - Page 1

Quand TIGCC produit des sections BSS dans les programmes _nostub, elles sont initialisées dans le code de démarrage ? De l’espace est alloué sur le tas ? Du coup il faut que le code de démarrage reloge les références aux variables de la section BSS ?
Pourquoi seules les variables non initialisées vont en section BSS ? Quelles sont les différentes conditions à remplir pour partir en section BSS ?

Bonus (question super conne) : c’est quoi l’avantage de la section BSS ? Les données sont réinitialisées à 0 à chaque appel du programme ? Mais sur d’autres plate-formes que les TI-68k, où de toute façon les programmes sont copiés au chargement, quels sont les avantages ?

Sasume (./1) :
Quand TIGCC produit des sections BSS dans les programmes _nostub, elles sont initialisées dans le code de démarrage ?

Dans mon souvenir, on peut demander l'initialisation des BSS à 0 dans les options du projet. Je lancerai une VM ce soir pour vérifier, si personne n'a répondu d'ici là.

(pour mémo, PreOS initialise à 0 systématiquement)

Sasume (./1) :
Du coup il faut que le code de démarrage reloge les références aux variables de la section BSS ?

Nécessairement, il n'y a pas d'autres moyens.

Sasume (./2) :
Bonus (question super conne) : c’est quoi l’avantage de la section BSS ? Les données sont réinitialisées à 0 à chaque appel du programme ? Mais sur d’autres plate-formes que les TI-68k, où de toute façon les programmes sont copiés au chargement, quels sont les avantages ?

Oui, les données sont réinitialisées à 0 si tu l'as demandé. Sinon, c'est aléatoire (ta BSS est un handle sur le tas).

Au niveau des 68k, je n'ai jamais vu l'intérêt des BSS.
Je préfère (dés/)allouer un handle (ça prend 20 octets à tout péter). Et ça évite tout relogement, ce qui est la plupart du temps un impératif à mes yeux.

./2: bss: pas de stockage dans l'image exécutable.

squalyl (./5) :
./2: bss: pas de stockage dans l'image exécutable.

Pas plus que quand tu stockes tes données dans un stack frame. L'utilisation est identique, avec le relogement et le code de démarrage en moins.

Sasume (./2) :
Mais sur d'autres plate-formes que les TI-68k, où de toute façon les programmes sont copiés au chargement, quels sont les avantages ?

Ne pas faire gonfler la taille de l'exécutable, parce qu'on se fiche du contenu initial. Si tu déclares un tableau global comme ça :
[code]int tableau[10000];[/code]
il sera placé dans la section BSS et ne prendra pas de place, le seul truc qui sera stocké c'est qu'il faut lui réserver 10000*sizeof(int) octets de mémoire au chargement du programme.

Si t'avais fait ça :
[code]int tableau[10000] = {0, 0, 0 ..... 0, 0};[/code]
ton programme grossirait de 10000 octets, pour stocker le contenu initial, et ce ne serait plus placé en BSS.

Sasume (./2) :
Les données sont réinitialisées à 0 à chaque appel du programme ?

Ça dépend de la plateforme, certaines le font, d'autre nom. Pour TIGCC je sais pas.

EDIT : cross

Folco (./6) :
Pas plus que quand tu stockes tes données dans un stack frame. L'utilisation est identique, avec le relogement et le code de démarrage en moins.

Avec quand même la différence que la taille de la pile est limitée, souvent beaucoup plus que la mémoire totale dispo. (Mais je sais pas si c'est vrai sur TI).

squalyl (./5) :
./2: bss: pas de stockage dans l'image exécutable.

OK, on indique juste la taille des données et c’est alloué automatiquement au chargement.

./6 Sauf que sur la pile on n’a que 16 ko alors qu’en RAM on a 200 ko. J’ai faux ?

Sasume (./1) :
elles sont initialisées dans le code de démarrage ?

Oui

Sasume (./1) :
De l’espace est alloué sur le tas ?

Oui

Sasume (./1) :
Du coup il faut que le code de démarrage reloge les références aux variables de la section BSS ?

Oui

Sasume (./1) :
Pourquoi seules les variables non initialisées vont en section BSS ?

Ce sont les variables valant 0 en mapping mémoire. Les variables non initialisées sont initialisées à 0.

Sasume (./1) :
Quelles sont les différentes conditions à remplir pour partir en section BSS ?

Valoir 0.

Sasume (./2) :
c’est quoi l’avantage de la section BSS ?

Ne prend pas de place dans l'executable.

Sasume (./2) :
Les données sont réinitialisées à 0 à chaque appel du programme ?

Oui.

Sasume (./2) :
Mais sur d’autres plate-formes que les TI-68k, où de toute façon les programmes sont copiés au chargement, quels sont les avantages ?

Séparer clairement les sections communes à multiples processus et uniques à chaque (entre autre).

Folco (./6) :
Pas plus que quand tu stockes tes données dans un stack frame

La section BSS est moins limitée en mémoire que la stack frame.

PpHd (./9) :

Sasume (./1) :
Quelles sont les différentes conditions à remplir pour partir en section BSS ?

Valoir 0.

Et avoir le qualifieur static ou bien être déclarée dans l’espace global, je me trompe ?

Sasume (./10) :

PpHd (./9) :

Sasume (./1) :
Quelles sont les différentes conditions à remplir pour partir en section BSS ?

Valoir 0.

Et avoir le qualifieur static ou bien être déclarée dans l’espace global, je me trompe ?

oui, bien sûr.

Les BSS ne sont pas forcément initialisés à zéro par le code de startup des programmes AMS native, en effet.

./6 Sauf que sur la pile on n’a que 16 ko alors qu’en RAM on a 200 ko. J’ai faux ?

C'est le bon ordre de grandeur. Les valeurs réellement utilisables sont légèrement inférieures.

Le gros défaut des BSS, ce sont les références xxx.l que cela nécessite pour accéder aux variables non explicitement initialisées. La différence de vitesse est assez négligeable, mais ça peut coûter très cher en place (décompressée, c'est celle qui importe à l'exécution): plusieurs KB (!) pour un programme de ~50 KB (exemple réel: TI-Chess *).
En général, dans les divers programmes de tiers auxquels j'ai contribué des optimisations, se passer de la section BSS était une optimisation taille (et évidemment vitesse, puisqu'on remplace certaines références xxx.l par des références d(pc)).

(*): dans les dernières versions de TI-Chess, j'ai mergé la section BSS avec la section DATA. En réalité, le binaire sans BSS (donc, avec des kilo-octets de zéros qui n'étaient pas présents auparavant) est globalement plus gros que le binaire avec BSS, mais la différence de taille est significativement inférieure à la taille qu'avait la section BSS (=> le code moins efficace pour accéder à la section BSS coûte plusieurs kilo-octets).

Lionel Debroux (./12) :

Les BSS ne sont pas forcément initialisés à zéro par le code de startup des programmes AMS native, en effet.

Ca, c'est un bug connu. Pas une feature.

Merci pour vos infos

Les BSS ne sont pas forcément initialisés à zéro par le code de startup des programmes AMS native, en effet.

Ca, c'est un bug connu. Pas une feature.

J'imagine que Kevin pense le contraire, comme d'hab

Il serait certainement bon de (re)poster les arguments (ou poster des liens) pour et contre la mise obligatoire à zéro des BSS par le code de startup, ce que ça coûterait (pas bien plus de 10-20 octets, certainement) et ce que ça risque de casser (à part les programmes qui utilisent la mémoire non initialisée comme source d'entropie, ce qui doit être particulièrement rare, je ne vois pas).

Sasume (./1) :
Quand TIGCC produit des sections BSS dans les programmes _nostub, elles sont initialisées dans le code de démarrage ?

Par défaut, oui, mais c'est désactivable (cf. les options du projet), mais dans ce cas leur contenu initial sera n'importe quoi étant donné qu'elles sont allouées en temps d'exécution.

De l’espace est alloué sur le tas ?

Oui.

Du coup il faut que le code de démarrage reloge les références aux variables de la section BSS ?

Oui.

Pourquoi seules les variables non initialisées vont en section BSS ?

Parce que la section n'est pas stockée dans le programme, donc il n'y a pas d'initialisateurs.

Quelles sont les différentes conditions à remplir pour partir en section BSS ?

Variable globale ou statique non initialisée, BSS activé dans le compilateur (non-utilisation de -mno-bss) et dans le linker (non-utilisation de MERGE_BSS), version suffisamment récente de TIGCC.

Sasume (./2) :
Bonus (question super conne) : c’est quoi l’avantage de la section BSS ?

On évite de se trimballer des kilooctets de zéros si on a de gros tableaux globaux.

PpHd (./9) :
Valoir 0.

Condition non suffisante, à moins d'utiliser -fzero-initalized-in-bss (qui est désactivé par défaut dans TIGCC pour des raisons de compatibilité et pour permettre de désigner une variable comme non-BSS pour éviter les relogements).

Ironiquement, ça veut dire que:
int toto;
vaudra toujours zéro au démarrage (parce que c'est dans la section BSS qui est initialisée au démarrage du programme) alors que:
int toto=0;
non! (Il garde la dernière valeur si le programme n'est ni archivé ni compressé.) C'est subtil, quoi.

PpHd (./13) :
Ca, c'est un bug connu. Pas une feature.

Non, cette option est une feature de ld-tigcc, mais ce n'est pas sans raison que le choix par défaut est d'initialiser le BSS (c'est ce que demande le standard C, entre autre).

Lionel Debroux (./15) :

Les BSS ne sont pas forcément initialisés à zéro par le code de startup des programmes AMS native, en effet.

Ca, c'est un bug connu. Pas une feature.

J'imagine que Kevin pense le contraire, comme d'hab
Il serait certainement bon de (re)poster les arguments (ou poster des liens) pour et contre la mise obligatoire à zéro des BSS par le code de startup, ce que ça coûterait (pas bien plus de 10-20 octets, certainement) et ce que ça risque de casser (à part les programmes qui utilisent la mémoire non initialisée comme source d'entropie, ce qui doit être particulièrement rare, je ne vois pas).

Désactiver l'initialisation automatique des BSS permet de gagner de la place dans certains programmes. Je ne vois pas ce que ça coûte d'avoir le choix.