Для компиляции исходников используется маке файл в gcc, Во время написания маке файла возник
вопрос, в каком порядке лучше компилировать файлы?, попробовал очередность поменял ошибок нет,
в сети поискал, не чего нужного не нашел, может есть какие рекомендации ?

Ну...., если-бы Вы до начала "написания" ознакомились с основополагающим принципом работы makе ( и про компиляторы-линкеры-библиотекари надо почитать, естественно в первую очередь ), то и вопрос не мог возникнуть в принципе

АБСОЛЮТНО безразлично.

а позволю себе вопрос: вот у компоновщика есть опция relax - когда он пытается заменить дальние джампы и вызовы подпрограмм короткими... и вот в случае, если из-за порядка сборки отельные секции расположатся рядом - этот этап даст существенный эффект, т.к. много "перекрестных" вызовов заменится на короткие, а если они окажутся далеко друг от друга - эффекта не будет. или компоновщик более интеллектуальный и тасует секции (если можно, конечно) уже после компиляции сам?
вообще, есть смысл в моих размышлениях или они надуманы?

есть такая опция -shared, которая позволяет видеть компилятору все исходники одновременно, что позволяет максимально оптимизировать код.
По-моему, так.

Секции располагаются согласно порядку указанному в скрипте линкера, если вас что-то не устраивает или есть сомнения - штудируйте мануалы и правьте скрипты.

а по-моему, совсем не так. и использовать -shared для AVR по-моему смысла не имеет.... кстати, это опция компоновщика, а не компилятора.


ладно, если вы прочли все мануалы, прошу вас ответить: а функции из модулей компонуются в секцию .text в порядке обработки модулей или как-то иначе? и на каком этапе выполняется замена дальних вызовов короткими - до компоновки всех функций всех файлов в одну секцию или после компоновки функций каждого файла?

Позволю себе заменить, что вопрос был о "компиляторе", а не о "линкере", хотя, возможно, автор их просто не отличает . Линкеры по нынешним временам, тоже стали навороченными и линкуют, бывает, не из классических "объектиков" из неких промежуточных представлений, но по любому даже, если речь идет о линкере оказать разумную помощь подсовывая ему объекты линковки в "оптимальном" порядке не светит.

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

P.S. C учетом того, что по идеологии GCC весь процесс компиляции и сборки может заключаться во вводе единственной командной строки для (как там правильно?) front-end компилятора, не удивительно, что многие начинают не различать компиляцию и компноновку

Предлагаете пересказать вам документацию? Линкер обрабатывает файлы в том порядке, в каком они указаны в его командной строке. Входные секции раскладываются в выходные в том порядке, который указан в скрипте линкера. А вариантов там предусмотрено множество - от поименного указания каждого файла или группы файлов до сортировки их по нескольким критериям. Т.е. это означает, что если в скрипте указана сортировка по именам и в командной строке указаны файлы a.o, c.o, b.o, то при добавлении секции text из b.o она будет вставлена между a.text и c.text. А если в скрипте не указана сортировка - то будет добавлена вслед за c.text

Но порядок компиляции не влияет ни на что.

программа gcc (gcc.exe) - драйвер. Она вызывает остальные программы (препроцессор, компилятор, ассемблер, линкер). Это легко увидеть, запустив компиляцию с ключем -v. front-end переводит текст с языка высокого уровня во внутреннее представление, back-end генерит из внутреннего представления ассемблерный текст для целевого процессора. Подробности тут.

не то чтобы предлагаю... а так, ненавязчиво намекаю если вы по каким-либо причинам ее освоили полностью - вам не сильно это трудно, а вот так взять и (даже просто бегло) прочитать всю документацию на GCC - это лично для меня просто непосильный труд! кое-что вычитываю, конечно, но чтобы все...

это было изначально ясно (мне). но вопрос - влияет ли на результат компоновки порядок поступления функций - остался открытым...

изначально ясно в квадрате

спасибо, с терминами бывают накладочки...

Если в скрипте не указана сортировка - то влияет. Секции будут уклыдываться в том порядке, в котором поступают на вход линкера. Т.е. в том порядке, в котором передаются объектные файлы, а внутри каждого файла - в том порядке, в котором генерились из исходника.

До этого еще далеко, но кое-что почитываем на досуге.

вот! и это важно! спасибо.

--combine --whole-program
combine для того, чтобы все перечисленные в командной строе исходники собрать в один объектник (сначала объединив в один исходник) а whole-program - чтобы рассматривал это как уже законченную программу. Благодаря этому неиспользуемые функции выбрасываются ещё не доходя до --gc-sections, мелкие функции "из другого файла" инлайнятся по месту и их отдельное тело выбрасывается (раз это уже вся программа, значит снаружи никто не вызовет) и т.д.
Вот только некоторые проблемы возникают, если в проекте есть асм-файл и он вызывет что-то из С-файла. С точки зрения собранных в кучу С-файлов та функция не вызывается вообще, поэтому она выбрасывается из файла а_тут_собраны_все_с.o и не находится при линковке.
Должно лечиться атрибутами used и externally_visible для той С-функции, которая вызывается из асм-файла, но пока не проверял, не очень зудит таким путём пытаться ещё уменьшить размер бинарника.

Да, аналогичная беда должна возникать при миксе С и С++, лучше и чисто-С-шные вещи тоже обрабатывать как С++, чтобы пошло на вход одного компилятора.

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

или я чего-то недопонял и недоделал?

Так его и не будет. Из разных модулей проинлайнить что-либо невозможно.