Полезность разбиения на логические модули не обсуждается. Полезно и все.
Еще полезно использовать системы отслеживания версий (VSS, Team Coherence и т.п.).

А по поводу кейла и текста (модулей):
1. Если вдруг понадобится разместить массив констант по определнному адресу, то придется
смотреть описание на кейл и переделывать исходный текст, чтобы это сделать.
Подробно см. директиву линковщика "CO". Пример из реального проекта управляющей строки линковщика "?CO?tb_crc8(0FA00H)" - разместить объект tb_crc8 в памяти CODE по адресу 0xFA00.
tb_crc8 - таблица предвычесленных значений tb_crc8[256].

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

Полезность разбиения на логические модули не обсуждается. Полезно и все.
Еще полезно использовать системы отслеживания версий (VSS, Team Coherence и т.п.).

А по поводу кейла и текста (модулей):
1. Если вдруг понадобится разместить массив констант по определнному адресу, то придется
смотреть описание на кейл и переделывать исходный текст, чтобы это сделать.
Подробно см. директиву линковщика "CO". Пример из реального проекта управляющей строки линковщика "?CO?tb_crc8(0FA00H)" - разместить объект tb_crc8 в памяти CODE по адресу 0xFA00.
tb_crc8 - таблица предвычесленных значений tb_crc8[256].

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

Я уже как-то писал и ссылки давал. Современные компиляторы устроены еще более наворочено и, в частности, используется оптимизация кода на уровне линкера. Лично сталкивался с такими штуками еще в Borland C++ 5.5 Вывод очень простой - максимально полно задавать нужные тебе параметры и опции при компиляции проекта, а не полагаться не режимы "по умолчанию" и грамотно применять расширения языка типа inline, volatile и пр.

С gcc (не знаю просто, как с другими) можно при большом желании и на ёлку влезть, и всё такое прочее.
Если указать в командной строке все .c файлы проекта сразу и добавить ключики -combine (объединить промежуточное представление всех файлов в одно целое) и -fwhole-program (и это объединение - вся программа), то он ведёт себя так, как якобы все функции этого общего представления статические, т.е. снаружи "этого всего" никому не нужны и проводит все эти оптимизации (выбрасывание ненужного, inline-подстановки используемого единственный раз либо достаточно мелкого). Для "окончательного релиза" это может и есть смысл делать.

А вот замены вызовов на ближние делает как раз линкер, причём в том числе при линковке нескольких объектников и делает это в том числе со включенными из бибилиотек модулями.
Ключ --relax

Разве уместен разговор о деньгах когда речь идет о проверенной информации ?

П.С. пардон а Вы не подсчитывали сколько денег Вы потратили на интернет читая этот форум ?

извиняюсь за офф.

У меня безлимитка 20 USD в месяц.
Что позволяет копировать, в среднем, в месяц 300-400 электронных книг.
Что значит "проверенная информация"? Это как рыба не первой свежести?

Лучше прочитать одну, чем скопировать 100.
Причём читать удобнее бумагу.
Я бы вот руководство по GCC с удовольствием купил, так не продают уже, ни за какие тысячи...
А на компе есть, 2 версии, русская и аглицкая. Только толку-то мало. С экрана читать тяжело. Особенно после рабочего дня.

М-м... У вас нет принтера?

Вот это зачОт! Спасибо, не знал о такой возможности.

А ещё функции можно дать атрибут externally_visible и её будет видно снаружи даже при ключе -fwhole-program :-)