web-dev-qa-db-fra.com

Quelles sont les parties de la base de code qui font que les binaires sont volumineux?

J'ai construit du code pour un simulateur et j'essaie maintenant d'utiliser la chaîne d'outils gratuite de TI pour effectuer une compilation croisée sur une cible avec 64 Ko de nvram. Le compilateur affirme que mon code dépasse de 34 ko la ROM:

(...) msp430-elf/bin/ld: region `ROM' overflowed by 33716 bytes

Une autre ligne indique qu'il ne peut pas contenir le champ .text dans l'espace qui lui est alloué. Je ne peux pas croire que mes ajouts totalisent 34 ko, sans parler du débordement des fichiers binaires de ce montant. 

  • Les fichiers .o que mon code a ajoutés au projet ne représentent qu'une petite fraction (200 Ko des 1,9 Mo) du projet, et j'ai retiré de nombreux composants du projet.
  • Je transmets déjà les indicateurs -Os -s au compilateur. 
  • Le nouveau code contient environ 100 caractères de littéraux de chaîne.
  • Mon code utilise de nombreuses fonctions math.h (en fait, il s'agit de la seule partie qui effectue de l'arithmétique en virgule flottante), appelez strtod et appelez sprintf.

Existe-t-il des outils ou des méthodes pour décomposer ce qui rend les fichiers binaires si volumineux?

cembeddedcross-compilingmicrocontroller
24
enthdegree

GNU binutils a des outils pour vous aider à déterminer la taille de chaque symbole ou simplement de chaque fichier objet. 

Regardez par exemple size: https://manpages.debian.org/jessie/binutils/size.1.en.html

nm vaut également la peine d'essayer, car il peut afficher la taille de chaque symbole dans le code de l'objet: https://manpages.debian.org/jessie/binutils/nm.1.en.html

Une inspection minutieuse des résultats de size et nm vous donnera l’intuition de savoir ce qui prend beaucoup de place et ce qui ne l’est pas.

Sachez que printf, sprintf et bon nombre des fonctions de bibliothèque les plus complexes peuvent souvent occuper quelques ko de ROM en plus. 

La prise en charge des virgules flottantes à l’aide de soft-floats alourdira également le code par rapport à l’utilisation de hard-float, c’est-à-dire l’utilisation de l’émulation logicielle par rapport aux instructions matérielles pour gérer les virgules flottantes.

Parfois, le compilateur ajoute une quantité incroyable de ballonnements :) 

20
Morten Jensen

Une fois, j’ai également eu des problèmes de mémoire avec un contrôleur MSP430 minuscule . La chaîne d’outils TI relie de grandes bibliothèques à votre binaire si des valeurs négatives sont possibles ou si la virgule flottante est utilisée. Dans mon cas, cela représentait environ 10% à 20% de l'utilisation totale de la mémoire.

Le logiciel gratuit Composer Studio de TI fournit une visualisation très puissante de la mémoire (Affichage -> Allocation de la mémoire).

Ce qui m'a beaucoup aidé a été de changer le modèle d'initialisation dans les paramètres de l'éditeur de liens et d'autres options d'optimisation. Je ne travaille actuellement pas avec un contrôleur MSP430, je ne peux donc pas vous donner plus de détails.

6
A.R.C.

Il existe également AMAP, un petit et facile à utiliser pour visualiser les fichiers .map: http://www.sikorskiy.net/prj/amap/

Il aurait été agréable d’avoir un outil semblable à kdirstat permettant de comparer visuellement la taille des symboles.

Bien que ce ne soit pas une réponse directe à la question, j'ai finalement utilisé l'implémentation CORDIC de Voidware pour éviter d'utiliser les fonctions volumineuses de <math.h>: https://github.com/enthdegree/cordic_wrapped

0
enthdegree