L'alignement de .Data et .bbs est parfois de 4 octets et parfois 32 octets.
Exemple 1: Selon la dernière colonne de la sortie ci-dessous, l'alignement des BSS et des données est 32 octets exemple 2: selon la sortie ci-dessous, le système d'exploitation d'alignement et .bbs est 4 octets P> bash-3.00$ readelf --sections ./a.out
There are 28 section headers, starting at offset 0x78c:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
...
[22] .data PROGBITS 0804956c 00056c 000034 00 WA 0 0 4
[23] .bss NOBITS 080495a0 0005a0 000004 00 WA 0 0 4
...
4 Réponses :
Je pense que ces différentes valeurs d'alignement ont été déterminées par des scripts ld
libmodel.so : section .Data align = 16, section .bbss align = 16
a.out : section .Data align = 4, section .bss align = 4
Depuis le libmodel.so indique clairement "AL 32" dans la dernière colonne, il semblerait que l'alignement spécifié aurait été spécifié comme 32 au lieu de 16,
Les sections .Data et .bss à Libmodel.So ont été alignées sur 32 octets. E.g, pour la section .Data, l'adresse est 01e221e0, cela signifie que les cinq derniers bits LSB ont été définis sur zéro. En d'autres termes, il aligne avec 32bytes.
Pourquoi est-ce parfois 4 octets et à d'autres moments 32 octets?
Une fois qu'un exécutable est chargé en mémoire, il est adressé via des adresses virtuelles de processus. Les contraintes d'alignement sont dues à l'adressage de l'adresse virtuelle. Par exemple, si vous regardez la page d'homme pour elf , consultez la description de SH_ADDRALign . C'est la raison pour laquelle différents objets ELF spécifient différentes exigences d'alignement. Vous pouvez expérimenter en modifiant la source de A.out pour inclure un double et voir si l'alignement change.
Remarque: Ceci s'applique uniquement à l'alignement de la mémoire. Il existe également une restriction d'alignement du fichier sur disque. Pourquoi? Je pense que cela serait d'aider à faciliter la cartographie des données de fichier aux structures de base poster la lecture du fichier. D'autres peuvent me corriger si je me trompe ici.
Mise à jour: souhaite clarifier une question. L'alignement d'adresse virtuelle est nécessaire uniquement en raison de la granularité d'accès à la mémoire sous-jacente appliquée par le chipset. Donc, le même programme compilé pour différentes architectures peut conduire à des restrictions d'alignement diff.
Il y a un livre vraiment agréable, qui vous donnera une excellente compréhension de votre question non seulement, mais tout ce qui concerne.
Le site Web du livre est ici
chapitre n. 7 est celui que vous recherchez.
Je ne sais pas si vous voulez une réponse directe, ou un plus sophistiqué, mais j'espère que cela aide.
Pour BSS, l'alignement est décidé à l'aide de la taille des types de données, s'il n'est pas aligné, le linker alignez d'abord l'adresse de variable où le démarrage des BSS peut être placé.
L'alignement des données est un détail de mise en œuvre du compilateur. Pourquoi cela compte-t-il? Quel problème essayez-vous de résoudre?
@lsk J'essaie de réduire la taille du segment de ma application .bbss de sorte qu'il consomme moins de mémoire sur un hôte de contrainte de ressources. Je m'attendrais à ce que les .bs sont égaux à la somme de tailles de tous les objets non initialisés définis dans l'espace mondial. Mais même si je réduit la taille d'un objet de 8 octets, il n'y a pas de réduction de la taille des .bbs. La table des symboles montre que la taille de l'objet a été réduite de 8 octets, mais il n'y a pas de changement de taille .bss. Il y a 10 000 objets de ce type, mais lorsque je réduit la taille de la classe de 8 octets, je ne vois aucun changement dans les .bs.