[Pavel V. 0]

Пытаюсь разобраться в скрипте линкера, возник вопрос.

 

В комплекте scmRTOS идут два скрипта: stm32f10x_flash_md.ld и stm32f10x_flash_md_kgp.ld. Они немного отличаются:

 

 

Насколько я понял, дело касается расположения конструкторов и деструкторов. Не подскажете, чем обусловлены эти правки?

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

Насколько я понял, дело касается расположения конструкторов и деструкторов. Не подскажете, чем обусловлены эти правки?

В предыдущих версиях gcc конструкторы жили в секции .ctors, в текущих - в секции .init_aray. В ваших скриптах в одном раскомментирована одна секция, во втором - вторая. Зачем - загадка. Видимо следы экспериментов автора с разными версиями компилятора. Расположение этих секций относительно остальных секций в .text значения не имеет. Я обычно вставляю в скрипт оба варианта, хотя уже давно не пользуюсь версией, использующей *.ctors:

    __ctors_start = .;
    KEEP(SORT(*)(.ctors))
    KEEP(SORT(*)(.init_array))
     __ctors_end = .;

 

[AHTOXA 14]

В комплекте scmRTOS идут два скрипта: stm32f10x_flash_md.ld и stm32f10x_flash_md_kgp.ld. Они немного отличаются:

Возьмите скрипты поновее здесь.

Насчёт разницы Сергей правильно объяснил, в то время как раз переезжали конструкторы, и в одном компиляторе они уже переехали, а в другом - ещё нет.

[Pavel V. 0]

Ребята, спасибо огромное! Это первый скрипт линкера, в котором я смог разобраться :) Остальные варианты, что мне попадались, представляют собой какое-то адское месиво.

 

А в какую секцию помещаются деструкторы?

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

А в какую секцию помещаются деструкторы?

А фиг его знает :) В мелкопроцессорных устройствах до вызова деструкторов глобальных объектов дело никогда не доходит, значит и линковать их не нужно.

 

[Pavel V. 0]

А фиг его знает :) В мелкопроцессорных устройствах до вызова деструкторов глобальных объектов дело никогда не доходит, значит и линковать их не нужно.

Да, действительно :) Однако, в других примерах, которые я смотрел, секции .fini_array и .dtors (похоже, именно в них должны помещаться деструкторы) присутствуют.

 

Осталось теперь отладку добить через J-Link и можно праздновать окончательный переход на GCC.

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

Да, действительно :) Однако, в других примерах, которые я смотрел, секции .fini_array и .dtors (похоже, именно в них должны помещаться деструкторы) присутствуют.

У меня тоже присутствовали. Пока безобидный проект при сборке под линухом чуток другой версией гцц вдруг не потащил за собой поддержку файловых операций и всего-прочего на несколько десятков К.

 

Осталось теперь отладку добить через J-Link и можно праздновать окончательный переход на GCC

OpenOCD через JTAG работает, swd пилят потихоньку.

[AHTOXA 14]

OpenOCD через JTAG работает, swd пилят потихоньку.

Вот тут проскочило сообщение, что SWD уже работает. (Сам пока не пробовал.)

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

Вот тут проскочило сообщение, что SWD уже работает.

Это радует. А я за списком рассылки слежу, там писали что вбросили что-то в реп, но автор активно трудится на вычленением этого ужаса в отдельную библиотеку и введением отдельного транспорта. JTAG через J-Link работает, это я использую. А SWD мой древний MT-Link не умеет, а когда у меня руки дойдут собрать нормальный, глядишь, уже и в OpenOCD все устаканется.

 

[Pavel V. 0]

OpenOCD через JTAG работает, swd пилят потихоньку.

Я пока использую родной GDB-Server от Segger-а, у них есть версия в т.ч. под Линукс (которую я и использую). В целом отладка работает, но сопровождается периодическими необъяснимыми вылетами.

 

OpenOCD тоже пробовал, но под ним отладку вообще запустить не удалось. Может быть вы мне поможете с конфигурацией?

 

Процессор у меня LPC1768, OpenOCD запускаю с параметрами типа -f /interface/jlink.cfg -f /target/lpc1768.cfg. Отладчик запускается, процессор распознается.

 

Но ни один из найденных вариантов инициализации отладки так и не заработал. Прикручивать пытаюсь к Eclipse.