[Ques 0]

Наткнулся на непонятную вещь: если я собираю "с нуля" (т.е. после 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

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

[aaarrr 63]

Тут логично было бы map-файлы сравнить.

[Ques 0]

Вот diff — на первый взгляд ничего криминального...

[aaarrr 63]

Лучше как два отдельных файла.

[Ques 0]

После первого запуска make, и после второго

pl2303.map0

pl2303.map1

Изменено 25 апреля, 2019 пользователем Ques
Увидел, что можно вложить файлы

[Ques 0]

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

[Jury093 2]

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

[Ques 0]

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

[AVI-crak 0]

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

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

[Ques 0]

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

[Сергей Борщ 119]

5 часов назад, Ques сказал:

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

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

[aaarrr 63]

Только +10% по объему как-то многовато.

[jcxz 184]

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

[VladislavS 29]

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

[aaarrr 63]

objdump -d -S xxx.axf > xxx.lst