Размер кода в Keil Опции

[Radiokrot]

Есть вопрос - в Keil, указывая в параметрах проекта 'Use Cross-Module Optimization', при многократной компиляции размер кода меняется (напр. компилим проект, получаем размер Code=64984; не меняя ничего в проекте ещё раз его компилим, получаем Code=64994 (разница в 10 байт)), настораживает... Не в курсе, с чем связано, и влияет ли на работу проекта в целом? ))

[aaarrr]

Эта опция включает использование линкером feedback-файла. Каждая следущая компиляция при этом использует результаты предыдущей. По-идее, после второй сборки размер кода меняться не должен.

[AlexandrY]

Замечал раньше такое, но вот в последнем Keil-е такой фокус как-то не удается.

Однако заметил, что Keil любит при включенной опции "one ELF section per function" располагать программные модули в памяти по алфавиту
Из-за этого соседние функции могут быть раскиданы хаотично по всей памяти и из-за этого появляются многочисленные вставки с указателями длинных переходов. В результате код вместо того чтобы сжаться может разрастись на пару десятков байт.
Даже при отключенной этой опции но оставшейся "Use cross-module optimization" все равно хочет расположить что-то по алфавиту.
Может с этим связаны колебания размеров.
Хотя при перестановке секций тож должны быть колебания из-за выравниваний структур данных в ro секциях.

Эта опция включает использование линкером feedback-файла. Каждая следущая компиляция при этом использует результаты предыдущей. По-идее, после второй сборки размер кода меняться не должен.

[defunct]

при многократной компиляции размер кода меняется

Для релиза всегда делайте clean build.
Это кстати не проблема Keil'а, это "фича" ARM'a. RVDS и SDT ведут себя также.

[aaarrr]

Для релиза всегда делайте clean build.

Интересно, а feedback'и clean удаляет? Если да, то совет вредный

[defunct]

Интересно, а feedback'и clean удаляет? Если да, то совет вредный

Совет не вредный в любом случае, разработчик (другой) который возможно будет исследовать кордамп после сбоя должен иметь возможность собрать идентичную прошивку. Clean build даст всегда идентичную сборку.

насчет feedback'ов, если с их наличием код растет, а не уменьшается, то какой в них смысл?

[aaarrr]

Совет не вредный в любом случае, разработчик (другой) который возможно будет исследовать кордамп после сбоя должен иметь возможность собрать идентичную прошивку. Clean build даст всегда идентичную сборку.

ИМХО, в этом случае нужно делать полный архив релиза, а не пытаться создать идентичную прошивку (какими-нибудь __DATE__ и __TIME__ она все равно может отличаться).

насчет feedback'ов, если с их наличием код растет, а не уменьшается, то какой в них смысл?

Ну, 10 байт - это еще не растет, хотя сам факт, конечно, настораживает.

[defunct]

ИМХО, в этом случае нужно делать полный архив релиза, а не пытаться создать идентичную прошивку (какими-нибудь __DATE__ и __TIME__ она все равно может отличаться).

тага в системе контроля версий недостаточно? скачал, собрал debug/release сборки и получил требуемые файлы.
Сборка одним и тем же армовским тулчейном с clean build'а всегда дает идентичный (bitexact) код! проверено.