Какие части кодовой базы делают двоичные файлы большими?

Question

Я создал некоторый код для симулятора и сейчас пытаюсь использовать бесплатный набор инструментов TI для кросс-компиляции с целью с 64 КБ nvram.Компилятор утверждает, что мой код примерно на 34 КБ больше, чем в ПЗУ:

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

В другой строке написано, что он не может вписать поле .text в выделенное ему пространство.Я не могу поверить, что мои добавления составляют 34 КБ, не говоря уже о том, что двоичные файлы переполняются на эту сумму.

• Файлы .o, которые мой код добавил в проект, составляют небольшую долю (200 КБ из 1,9 МБ) от общего объема проекта, и я вынул большое количество компонентов, которые были впроект для начала.
• Я уже передаю компилятору флаги -Os -s.
• Новый код содержит около 100 символов строковых литералов.
• Мой код использует много функций math.h (фактически это единственная часть, которая выполняет арифметику с плавающей запятой), сделайте вызовна strtod и позвоните на sprintf

Существуют ли какие-либо инструменты или методы для определения причин, по которым двоичные файлы становятся такими большими?

Answer 1

У меня когда-то также были проблемы с памятью на крошечном контроллере MSP430.Цепочка инструментов TI связывает большие библиотеки в ваш двоичный файл, если возможны отрицательные значения или используется плавающая точка.В моем случае это было около 10% - 20% от общего объема используемой памяти.

Бесплатная программа TI Code Composer Studio обеспечивает очень мощную визуализацию памяти (View -> Memory Allocation)

Что помоглоЯ много менял модель инициализации в настройках компоновщика и другие варианты оптимизации.В настоящее время я не работаю с контроллером MSP430, поэтому больше не могу рассказать вам подробности.

Answer 2

Существует также AMAP, небольшой и простой графический интерфейс для просмотра файлов .map: http://www.sikorskiy.net/prj/amap/

Было бы неплохо иметь инструмент, похожий на kdirstat, который позволяет визуально сравнивать размеры символов.

Хотя это и не прямой ответ на вопрос, я в конечном итоге использовал реализацию CORDIC Voidware, чтобы избежать использования больших функций в <math.h>: https://github.com/enthdegree/cordic_wrapped

Answer 3

GNU binutils имеет инструменты, которые помогут вам определить размер каждого символа или только каждого объектного файла.

Взгляните на size, например: https://manpages.debian.org/jessie/binutils/size.1.en.html

nm также стоит попробовать, так как он может показать размер каждого символа в коде объекта: https://manpages.debian.org/jessie/binutils/nm.1.en.html

Тщательная проверка выводов size и nm даст вам интуицию в отношении того, что занимает много места, а что нет.

Знайте, что printf, sprintfи многие из более сложных библиотечных функций часто могут занимать несколько КБ дополнительного ПЗУ.

Поддержка чисел с плавающей запятой с использованием soft-float также приведет к увеличению объема кода по сравнению с использованием hard-float, то есть с использованием программной эмуляции и аппаратных инструкций для обработки с плавающей запятой.

Иногда компилятор добавляетудивительное количество наворотов :)