Почему адрес вектора сброса может отличаться, если две прошивки связаны одним и тем же сценарием компоновщика?

Question

У меня есть чип Cortex-M3, и на нем я запускаю загрузчик, который использует eCos. Загрузчик, после проверки обновлений прошивки и т. Д., Переходит в другое место (BASE_ADDRESS_OF_APP + 0x19) в ПЗУ, где находится реальное приложение (также скомпилированное с eCos).

Теперь вместо запуска обычной прошивки я хочу запустить мои CppUTests, скомпилированные для цели Cortex-M3. Таким образом, я могу скомпилировать и связать свои тесты для целевой платформы, используя ecos glibc, но не реальную операционную систему. Но когда я загружаю его на свою доску с помощью JTAG, он не запускается.

После некоторых исследований с использованием arm-eabi-objdump я обнаружил, что вектор сброса firmare CppUTest имеет смещение 0x490, а не 0x18 для обычной прошивки. Я подозреваю, что это причина, по которой тесты никогда не выполняются. Это правильно?

Как это возможно, что две прошивки имеют разные начальные адреса, когда я связываю их одним и тем же сценарием компоновщика?

Как я могу убедиться, что начальная точка тестовой программы совпадает с начальной точкой приложения?

Answer 1

Это зависит от того, как написан ваш скрипт компоновщика. Если адрес вашей точки входа не установлен в статическом местоположении в скрипте компоновщика, тогда может быть вероятность того, что другие данные / код будут эффективно помещены в объектный файл перед вашей точкой входа. перемещение места вашей точки входа и действительно вызывает проблемы.

Обычно я решаю эту проблему, создавая новый раздел, содержащий только 1 символ, и инструкцию перехода / перехода следующим образом:

.section entryPointSection
b myCodeEntryPoint

Затем в вашем скрипте компоновщика положить entryPointSection по жестко закодированному адресу, на который будет переходить ваш загрузчик.

myCodeEntryPoint label может быть именем функции C (или метки сборки, если необходимо), которая находится в обычном разделе.text и может быть связана в любом месте в пределах досягаемости jmp. Он станет вашей отправной точкой, но вам все равно, где он находится, потому что компоновщик должен найти его и правильно связать.

Если у вас есть дополнительные вопросы, рассмотрите возможность размещения скрипта компоновщика.