Pourquoi l' .segment bss nécessaire?

Ce que je sais, c'est que globales et les variables statiques sont stockées dans le .data segment, et des données non initialisées sont dans le .bss segment. Ce que je ne comprends pas, c'est pourquoi nous avons segment dédié pour les variables non initialisées? Si une variable non initialisée a une valeur attribuée au moment de l'exécution, la variable existe pas encore dans le .bss segment seulement?

Dans le programme suivant, a est dans le .data segment, et b est dans le .bss segment; est-ce exact? Veuillez me corriger si ma compréhension est erronée.

#include <stdio.h>
#include <stdlib.h>

int a[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9};
int b[20]; /* Uninitialized, so in the .bss and will not occupy space for 20 * sizeof (int) */

int main ()
{
   ;
}

Aussi, envisager la suite du programme,

#include <stdio.h>
#include <stdlib.h>
int var[10];  /* Uninitialized so in .bss */
int main ()
{
   var[0] = 20  /* **Initialized, where this 'var' will be ?** */
}

Vous pouvez lire BSS que Mieux Économiser de l'Espace.

InformationsquelleAutor Whoami | 2012-03-02

c compiler-construction linux

81

La raison est de réduire la taille du programme. Imaginez que votre C programme s'exécute sur un système embarqué, où le code et toutes les constantes sont enregistrées dans la vrai ROM (mémoire flash). Dans ces systèmes, l'initiale de "copier-bas" doivent être exécutées de manière à définir ensemble statique de la durée de stockage des objets, avant main() est appelée. Il sera généralement aller comme ce pseudo:
```
for(i=0; i<all_explicitly_initialized_objects; i++)
{
  .data[i] = init_value[i];
}

memset(.bss, 
       0, 
       all_implicitly_initialized_objects);
```
Où .les données et les .bss sont stockées dans la RAM, mais init_value est stocké dans la ROM. Si il avait été l'un segment, puis la ROM devait être rempli avec beaucoup de zéros, en augmentant la taille de la mémoire ROM de manière significative.

En fonction de RAM exécutables fonctionnent de la même façon, même si bien sûr ils n'ont pas de vrai ROM.

Aussi, memset est probable que certains très efficace assembleur en ligne, ce qui signifie que le démarrage de la copie peut être exécuté plus rapidement.
- Pour clarifier: la seule différence entre les deux .les données et les .sev, c'est que les start-up, le "copier-bas" peuvent être exécutées de manière séquentielle, donc plus rapide. Si ce n'était pas divisé en deux segments, puis l'initialisation auraient à sauter, la mémoire vive de spots appartenance à la non initialisée variables, afin de perdre du temps.
InformationsquelleAutor Lundin
74

La .bss segment est une optimisation. L'ensemble de la .bss segment est décrit par un seul nombre, probablement 4 octets 8 octets, ce qui donne à sa taille dans le processus en cours d'exécution, alors que le .data section est aussi grand que la somme des tailles des initialisé les variables. Ainsi, la .bss rend les exécutables plus petits et plus rapides à charger. Sinon, les variables pourrait être dans le .data segment avec l'initialisation explicite de zéros; le programme aurait du mal à faire la différence. (Dans le détail, l'adresse des objets dans .bss serait probablement différente de l'adresse si elle était dans l' .data segment.)

Dans le premier programme, a serait dans le .data segment et b serait dans le .bss segment de l'exécutable. Une fois que le programme est chargé, la distinction devient immatériel. Au moment de l'exécution, b occupe 20 * sizeof(int) octets.

Dans le deuxième programme, var est alloué pour l'espace et l'affectation dans main() modifie l'espace. Il se trouve que l'espace pour var a été décrite dans le .bss segment plutôt que de la .data segment, mais cela n'affecte pas la façon dont le programme se comporte lors de l'exécution.
- Par exemple, envisager d'avoir beaucoup de non initialisée tampons de 4096 octets de longueur. Voudriez-vous tous ceux 4k tampons de contribuer à la taille du binaire? Ce serait beaucoup d'espace perdu.
- killer : Pourquoi l'ensemble du segment bss décrit par un seul numéro?
- Combien de nombres vous pouvez utiliser à la place?
- Je veux dire tous les zéro initialisation des variables statiques va dans la bss . Donc ne devrait pas être sa valeur d'être tout à zéro ?et aussi pourquoi ne sont-ils pas donné l'espace sur .les données de la section comment faire alors assurez-il lent ?
- Reportez-vous à Cette Question: "stackoverflow.com/questions/8385322/..." . Je pense que l'sélectionnée comme meilleure réponse est fausse explication de ce qu'est statique d'allocation de mémoire. Pouvez-Vous Confirmer ? .
- le numéro enregistré est le nombre d'octets à être rempli avec des zéros. À moins qu'il n'existe pas de telles variables non initialisées, la longueur de la section bss ne sera pas zéro, même si tous les octets I nfi section sera mise à zéro une fois que le programme est chargé.
- Oh ok. Je la comprends . Et Aussi pourquoi l'aide .les données pour ce qui est lent.? Et s'il vous Plaît voir la question que j'ai écrit sur ci-dessus. Comme il va induire en erreur bon nombre de nouveaux arrivants. Choisis la meilleure réponse n'est pas correcte.
- Je suis allé et édité qui a accepté de répondre parce qu'il a été, au mieux, trompeuses. Il y a place pour soutenir que mon montage est trop de fond. Notez que le plus voté réponse était déjà mieux. Suivre le vote, non seulement acceptées vs non reconnus du statut.
- Merci beaucoup. Je viens de voir ton edit. Vous avez raison que la réponse est si trompeur. Il misleaded moi. Et puis j'ai lu la plupart des upvoted réponse et éclaircir mes doutes. Étrange que de mauvaise réponse devenu point culminant de toutes les réponses et d'être sélectionné comme meilleure réponse.
- Les octets dans le .les données de la section à lire à partir de "disque" (plateaux magnétiques en rotation, ou à l'état solide). Il faut du temps pour lire les données. En revanche, la lecture de 8 octets pour la taille du segment bss est trivial (par rapport à la lecture de 64 mo de zéros sur le disque, par exemple) et ensuite le réglage de la mémoire à zéro. De Plus il gaspille de l'espace disque — pourquoi stocker 64 MiB de zéro lorsque vous pouvez stocker seulement 8 octets en disant: "il y a 64 mo de zéros". Plus il prend de l'espace sur les sauvegardes — vous vous en rappelez?
- Beaucoup de Gens ont Demandé à La Personne Qui a écrit la réponse pour le modifier .Mais il n'a pas .J'ai pensé que je pourrais le modifier . Mais alors je n'ai pas cru en moi-même que la réponse est vraiment mauvais.
- À ce stade, il est probablement mieux que je ne le modifier qu'à vous. Votre édition devrait être revue et pourrait ne pas le faire par le biais de ('changement de l'auteur du sens"). Pour le pire ou pour le pire, j'ai plus de rep, en particulier w.r.t la C marque, de sorte que je peux peut-être sortir avec lui sans trop de ructions. Mais le répondeur pourrait décider de mon édition n'est pas valide et rouler le changement; je n'avais pas contredire lui (mais j'irais ajouter un downvote que je n'ai pas encore fait).
- Je Comprends .Je voulais juste voir la meilleure réponse qui soit au moins correcte et de ne pas tromper les gens, spécialement les nouveaux arrivants . Aussi je veux savoir que vous avez dit sev, il est stocké le nombre d'octets serait rempli de zéro. Je veux demander, lorsque le programme est exécuté, alors par exemple si il y a 2 statique non initialisée ou initialisées à zéro de la variable. Le sev section contient le nombre d'octets à écrire à 0. Lorsque le programme est exécuté où sont les réels 0 octets écrits dans ,segment de données ou lorsque, en raison sev section indique seulement le nombre d'octets pour être mis à zéro, il n'a pas lui-même les magasins static int i = 0.
- Aussi, Si c'est d'écrire static int i[100] = {1,2,3....} .Alors mon exécutable 4*100 octets de plus grand. ?? Ou n'en .data l'article, il ne dit où en mémoire le tableau statique serait stocké comme à partir de l'adresse 0X00000000 à 0x10232333 quelque chose comme ça. Vous avez dit .data section est aussi grand que la somme des tailles des initialisé les variables.
- L' .sev section dans le fichier exécutable est un nombre. L' .sev section dans le processus de la mémoire d'image est normalement mémoire adjacente à la .les données de la section et souvent le moteur d'exécution .les données de la section est combiné avec la .bss; aucune distinction n'est faite dans la mémoire d'exécution. Parfois, vous pouvez trouver l'emplacement de la bss commencé (edata). Dans la pratique, l' .sev n'existe pas en mémoire une fois le processus de l'image est terminé, la mise à zéro des données est assez simple .section de données. Mais les détails varient en fonction de l'o/s, etc.
- La partie initialisation de tableau i devront être stockées dans la section de données, car il doit être auto-contiguës, et il n'y a aucun moyen de s'assurer qu'il n'y a pas d'autres données initialisées avant et après elle, de sorte que la seule façon de s'assurer que les valeurs correctes sont stockés est de garder les 100 int (400 octets) de données dans la .les données de la section de l'exécutable. Si c'était le dernier tableau dans .de données, puis, en théorie, vous pouvez avoir 3 int initialiseurs dans .données et 97 des zéros .bss. Je peux prédire que cela n'arrive pas dans la vraie vie.
- Cela signifie donc que si au moment de l'exécution de toutes les variables statiques qui sont explicitement ou implicitement initialisé à zéro sera stocker dans .data section . Ou dans quelques section et il n'y aura pas .bss Désolé, je me demande si beaucoup de question je veux juste que les choses dans ma tête. Aussi Pourriez-Vous suggérer certaines ressources comme le livre ou la chose pour l'étude de cette. Les pointeurs sur c livre comment est-il ?
- Ici "stackoverflow.com/questions/21350478/...", il est écrit que dans .section de données seulement il est écrit l'adresse mémoire où la statique initialisé les variables d'ira et de la valeur elle-même ne sont pas stockées.
- Ce que je voulais dire quand j'ai écrit static int i[100] = {1,2,3,...} est que tous les lieux sont initialisées à 1 , 2 ,3 et ainsi de suite.
- le temps. Trop de chat. Je dois faire semblant de travailler.
- Ok, je comprends . Merci beaucoup pour le garder avec moi. Aussi pour la correction de cette réponse, il aidera beaucoup.
InformationsquelleAutor Jonathan Leffler
12

De Langage d'assemblage étape par Étape: Programmation avec Linux par Jeff Duntemann, concernant la .les données section:

La .les données section contient des définitions de données de initialisé éléments de données. Initialisé
les données sont des données qui ont une valeur avant le début du programme en cours d'exécution. Ces valeurs
font partie du fichier exécutable. Ils sont chargés en mémoire lorsque l'
fichier exécutable est chargé en mémoire pour l'exécution.

La chose importante à retenir à propos de l' .les données de l'article, c'est que l'
plus initialisé éléments de données que vous définissez, plus le fichier exécutable
sera, et plus il faudra de temps à charger à partir du disque dans la mémoire
lorsque vous l'exécutez.

et la .sev section:

Pas tous les éléments de données doivent avoir des valeurs avant le début du programme en cours d'exécution.
Lorsque vous êtes en train de lire des données à partir d'un fichier sur disque, par exemple, vous avez besoin d'avoir un
place pour que les données puissent aller après elle vient à partir du disque. Tampons de données de ce type sont
défini dans le .sev la section de votre programme. Vous mettre de côté un certain nombre de
octets pour un tampon et de donner de la mémoire tampon d'un nom, mais vous ne dites pas quelles sont les valeurs
sont présents dans la mémoire tampon.

Il y a une différence cruciale entre les éléments de données définis dans la .données
section et les éléments de données définis dans la .sev section: les éléments de données dans le
.les données de la section ajouter à la taille de votre fichier exécutable. Les éléments de données dans
l' .sev section ne le font pas. Une mémoire tampon qui prend en hausse de 16 000 octets (ou plus,
parfois beaucoup plus) peuvent être définies .sev et ajouter presque rien
(50 octets pour la description) vers le fichier exécutable de taille.

InformationsquelleAutor mihai
9

Bien, tout d'abord, ces variables dans votre exemple ne sont pas initialisées; C indique que les variables statiques qui n'est pas autrement initialisé sont initialisées à 0.

Donc, la raison pour .l'option bss est d'avoir de petits fichiers exécutables, de gagner de l'espace et de permettre un chargement plus rapide du programme, le chargeur peut seulement attribuer un tas de zéros au lieu de copier les données à partir du disque.

Lors de l'exécution du programme, le programme chargeur charge .les données et les .sev dans la mémoire. Écrit dans les objets résidant dans .de données ou de .sev donc uniquement de la mémoire, elles ne sont pas vidées dans le binaire sur le disque en tout point.

InformationsquelleAutor janneb
4

La Système V ABI 4.1 (1997) (AKA ELFE de la spécification) contient également de la réponse:

.bss Cette section présente des données non initialisées qui contribuent à la
programme de la mémoire d'image. Par définition, le système s'initialise le
de données avec des zéros lorsque le programme commence à courir. La section occupe pas d'espace fichier, comme indiqué par le type de section, SHT_NOBITS.

dit que le nom de la section .bss est réservé et a des effets spéciaux, en particulier, il occupe pas d'espace fichier, donc l'avantage sur .data.

L'inconvénient est bien sûr que tous les octets doivent être mis à 0 lorsque le système d'exploitation met en mémoire, ce qui est plus restrictif, mais elles ont en commun de cas d'utilisation et fonctionne très bien pour les variables non initialisées.

La SHT_NOBITS type de section de la documentation répète cette affirmation:

sh_size Ce membre donne la taille en octets. À moins que la sec-
tion est de type SHT_NOBITS , la section occupe sh_size
octets dans le fichier. Une section de type SHT_NOBITS peut avoir une valeur non nulle
la taille, mais ça occupe pas d'espace dans le fichier.

Le C standard ne dit rien sur les articles, mais on peut facilement vérifier que la variable est stockée dans Linux avec objdump et readelf, et de conclure que les variables globales non initialisées sont en fait stockées dans le .bss, voir par exemple cette réponse: https://stackoverflow.com/a/36725211/895245
- veuillez expliquer. Je ne l'ai pas amélioré les réponses existantes légèrement avec un standard de devis? 😉
InformationsquelleAutor Ciro Santilli 新疆改造中心法轮功六四事件
3

L'article de wikipédia .sev offre une belle explication historique, étant donné que le terme est à partir du milieu des années 1950 (youpi mon anniversaire;-).

Retour dans la journée, tout était précieux, de sorte que toute méthode de signalisation réservés vide de l'espace, a été utile. Ce (.sev) est celui qui a coincé.

.les données sections sont pour l'espace qui n'est pas vide, au contraire, il devra (vos) la définition des valeurs entré en elle.

InformationsquelleAutor Philip Oakley

Vous devez vous connecter pour publier un commentaire.