Jump to content

    

arm-none-eabi-gcc под STM32F0, разный размер бинарника

Наткнулся на непонятную вещь: если я собираю "с нуля" (т.е. после make clean), то получаю:

   text    data     bss     dec     hex filename
   5612      16    1560    7188    1c14 mk/pl2303.elf

Но стоит мне просто обновить дату любого файла (просто командой touch file), как чудесным образом итоговый размер меняется:

   text    data     bss     dec     hex filename
   6224      16    1556    7796    1e74 mk/pl2303.elf

При этом абсолютно все объектные файлы остаются неизменными...

Версия gcc: 8.2.1 (свежий из армовской сборки, "родной" из репозитория не использую, т.к. там какая-то проблема с софтовым делением для STM32F0). Обновил буквально только что, до этого у меня был 7.3.1, и там собственно на эти проблемы я и наткнулся!

Вряд ли виноват ccache, т.к. иначе у меня arm-none-eabi-gcc была бы симлинком на ccache, а он — симлинк на arm-none-eabi-gcc-8.2.1

На удивление оба бинарника одинаково нормально работают при прошивке на МК. Но не нравится вот такое непонятное поведение: как ни с того, ни с сего размер собираемого файла может меняться?

Share this post


Link to post
Share on other sites

Более-менее причесал код, но проблема с изменением размера бинарников не исчезла. Интересно, что в других "проектах" такой проблемы нет! Чертовщина какая-то...

Share this post


Link to post
Share on other sites
1 час назад, Ques сказал:

Более-менее причесал код, но проблема с изменением размера бинарников не исчезла. Интересно, что в других "проектах" такой проблемы нет! Чертовщина какая-то...

для интереса собрал, всегда одинаковый размер:

   text    data     bss     dec     hex filename
   6468      16    1572    8056    1f78 mk/pl2303.elf

jury093@jury093:~/src/eddyem/stm32samples/F0-nolib/pl2303$ touch main.c

   text    data     bss     dec     hex filename
   6468      16    1572    8056    1f78 mk/pl2303.elf

jury093@jury093:~/src/eddyem/stm32samples/F0-nolib/pl2303$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
Copyright (C) 2018 Free Software Foundation, Inc.

там более полный лог: https://pastebin.com/rcVRZeTk

Share this post


Link to post
Share on other sites

Непонятно вообще... Может, это ccache выпендривается?

Share this post


Link to post
Share on other sites

Разница появляется на сборке usb. Точнее на перестановке местами функций во флеш памяти, и как следствие - изменение расстояния до переменных и констант. В некоторых случаях адрес получается коротким.

Смена даты создания (не изменения!!!) файла влияет на порядок обработки компилятором в случае раздельной компиляции. Сначала самое старое, оно возможно не требует обработки и может быть кэшировано. Эта функция пришла из мира больших машин, и порядком поднасрала во многих местах.

Share this post


Link to post
Share on other sites

Что значит "адрес получается коротким"? Это ж только в пиках так было, что можно было либо обычную адресацию использовать, либо "короткую". А здесь такого быть не должно...

Share this post


Link to post
Share on other sites
5 часов назад, Ques сказал:

А здесь такого быть не должно...

Мир не идален. Здесь такое тоже есть.

Share this post


Link to post
Share on other sites

Взять листинги одной и той же функции, но имеющей разный размер в разных вариантах компиляции и сравнить. Чего гадать-то?

Share this post


Link to post
Share on other sites

На gcc нормальный листинг получить не простая задача. Может кто поделится таинством?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now