Почему GCC помещает вызовы конструкторов глобальных экземпляров в разные секции (в зависимости от цели)?

У меня есть несколько простых объявлений глобальных экземпляров с непустыми конструкторами. Эти конструкторы вызываются при запуске автоматически. Я кросс-компилирую C ++ в Linux для разных целей микроконтроллера.


Что касается

  • рука-ни-EABI-GCC-4.8.4
  • rx-elf-gcc-4.8-GNURX_v14.03 (GCC 4.8.3)

вызовы конструкторов помещаются в .init_array раздел. Файл карты выглядит так:

.init_array 0x00007cb8 0x4 libmotor.o

.init_array 0x00007cbc 0x4 libaudio.o


Что касается

  • MIPS-эльф-GCC-4.8.2
  • АРН-GCC-4.8.1
  • MSP430-GCC-4.6.3

эти звонки попадают в .ctors раздел:

.ctors 0x000000009d011508 0x4 libmotor.o

.ctors 0x000000009d01150c 0x4 libaudio.o


Компиляция была сделана с -ffunction-sections -fdata-sectionsлинкер получил --gc-sections,

Все двоичные файлы работают, но я бы хотел поместить все вызовы в один и тот же раздел (чтобы упростить обслуживание сценариев компоновщика).

  • Почему существуют разные целевые разделы?
  • Можно ли изменить раздел по умолчанию с помощью параметра командной строки?
  • Если параметр командной строки не завершается: возможно ли определить раздел по умолчанию во время компиляции GCC?

6

Решение

Существует долгая дискуссия в Ошибка 46770. Замените .ctors / .dtors на .init_array / .fini_array на поддерживающих их целях.

Я извлек некоторые предметы, которые объясняют ситуацию:

Почему сделал .init_array включи?

  • Мы добавили .init_array/.fini_array для того, чтобы смешать версию SVR4 .init, который содержал реальный код, с версией HP-UX, который содержал указатели функций и использовал DT_INIT_SZ запись в динамический массив, а не пролог и эпилог, полученные из файлов crt * .o. Версия HP-UX рассматривалась как улучшение, но она не была совместима, поэтому мы переименовали разделы и записи динамической таблицы, чтобы две версии могли жить бок о бок, и реализации могли медленно переходить от одной к другой. ,

  • На HP-UX мы использовали .init/.init_array для статических конструкторов, и они зарегистрировали соответствующие статические деструкторы на специальном atexit список, а не добавление деструкторов к .fini_array, чтобы мы могли обрабатывать деструкторы на dlclose() события правильно (в зависимости от вашей интерпретации «правильно» в этом контексте)

Порядок исполнения отличается между .ctors а также .init_array

Отсталый порядок .ctors раздел

Некоторые программы могут неявно полагаться на тот факт, что глобальные
конструкторы в архивах, связанных позже, запускаются перед конструкторами в
объект связан с этими архивами. То есть дано

g++ foo.o -lbar

где bar это статический архив, а не разделяемая библиотека, то в настоящее время
глобальные конструкторы в объектах, извлеченных из libbar.c, будут выполнены
перед глобальными конструкторами в foo.o. Это был намеренный выбор
потому что это скорее будет правильным, чем наоборот. Тем не менее
Стандарт C ++ не гарантирует этого, поэтому любые программы, которые полагаются на это
заказ технически недействителен.

Проблема обратного порядка .ctors

Большая работа была проделана в обоих GNU ld а также gold переместить конструкторов из .ctors в .init_array, все, чтобы улучшить время запуска для Firefox

С помощью .init_array/.fini_array вместо .ctors/.dtors устраняет необходимость в связанных (относительных) перемещениях и позволяет избежать обратного поиска диска при запуске (поскольку .ctors обрабатываются в обратном направлении, .init_array обрабатывается вперед).

Переход от .ctors в .init_array

Основные версии обоих GNU ld а также gold сейчас поставь .ctors разделы в .init_array разделы и положить .dtors разделы в .fini_array разделы.

Комментарий: Возможно, введен с GCC 4.7.

РУКА

ARM EABI использует .init_array с первого дня.

Комментарий: Тем не менее, скрипт компоновщика по умолчанию содержит .ctors выходной раздел.

Конфигурация GCC

Один из вариантов — настроить gcc с помощью —disable-initfini-array.

Комментарий: эта опция не отображается при выводе mips-elf-gcc -v (-v показывает «Настроено с помощью: …»).

4

Другие решения


По вопросам рекламы [email protected]