Просмотр полной версии : SDCC релокация
В своих страданиях на тему системности я дошел до перемещаемых библиотек. https://github.com/salextpuru/sdcc-noinit/tree/master/libsrc
И тут меня ждало горькое разочарование.
Интерфейс я продумал. Он работает. Но вот с таблицей релокации не получается.
Суть в том, что sdldz80 (линкер) не выдаёт таблицу и я написал простой скрипт, который сравнивает два откомпилированных по разным адресам файла. Но плохое состоит в том, что SDCC часто генерирует код, где используются половинки адреса. И как с этим быть не знаю. Метод сравнения двух файлов не работает.
То есть например, есть массив:
_array: .ds 200
И SDCC шпарит код навроде:
ld l,# (_array & 0x0F)
.......
ld h,# (_array >> 8)
Разумеется, сравнением двуж таблиц ни фина не сделать :(
Как заставить линкер выдавать таблицу перемещений? Или как её вообще получить? Она получается не простой.
Error404
16.05.2018, 15:30
Как заставить линкер выдавать таблицу перемещений? Или как её вообще получить? Она получается не простой.
Обычно линкер такое должен уметь. Но генерирует ту таблицу обычно не он, а ассемблер (он генерирует перемещаемый оттранслированный код), а линкер на основе кода и включенной в перемещаемый код таблицы перемещений уже транслирует на определенный адрес и опционально подтягивает и включает в код прочие аналогичные модули из библиотек. Я от SDCC отказался намного ранее, поэтому конкретными деталями о нем не владею. Но мысль - поискать опцию в ассемблере а не линкере. Например ассемблер М80 при указании ключа /L генерирует файл с листингом (*.PRN) где в конце файла содержится таблица с адресами и именами всех символов (которые зная исходный и требуемый адрес посадки кода легко по этой таблице откорректировать).
Обычно линкер такое должен уметь. Но генерирует ту таблицу обычно не он, а ассемблер (он генерирует перемещаемый оттранслированный код),
Я наверное не ясно выразился. Ассемблер генерирует объектные файлы типа .rel. То есть "перемещаемые". А линкер соединяет эти объектные файлы воедино и привязывает к адресам.
Таблица ассемблера мне ничего не даст, так как я не знаю какой из объектников как линкер распихает по памяти. Там же еще и секции есть.
Мне же надо после загрузки в спек пересчитать адреса. Если все адреса хранятся как 16-битные - задача элементарно решается - сравнением двух файлов. (у меня один с адреса 0 линкуется, второй - с адреса 1).
Но если компилятор использует половинки адреса отдельно - то всё.
чем lst файл не нравится? все адреса там есть.
чем lst файл не нравится? все адреса там есть.
Там только один исходник в lst файле. а мне надо для всего бинаря, в который входит несколько объектников плюс библиотеки.
Мне нужна таблица символов, которую по сути линкер генерит внутри себя. Но наружу он её не показывает, сцука:)
странно. всё что собирает сдцц, всё видно в лст файле. из библиотек, из рел файлов. все адреса собранные линкером там есть. если ты часть бинаря собираешь не в сдцц, смотри тамошний лст файл. в общем, не совсем понятно что нужно. проект собирается в сдцц полностью, значит всё будет в лст файле.
странно. всё что собирает сдцц, всё видно в лст файле. из библиотек, из рел файлов. все адреса собранные линкером там есть. если ты часть бинаря собираешь не в сдцц, смотри тамошний лст файл. в общем, не совсем понятно что нужно. проект собирается в сдцц полностью, значит всё будет в лст файле.
Есть несколько исходников и библиотек. Они скомпилированы в .rel и .lib файлы с помощью SDCC.
Потом они линкуются в единый HEX с помощью sdld. ну и далее - в бинарь, но это несущественно.
SDCC для каждого из файлов исходников создаёт отдельный .lst файл. В нём все адреса относительные. Можно линкеру сказать, чтобы он делал .rst файлы. Там адреса абсолютные. Но опять же - один файл .rst на один .c файл.
Во-первых мне надо таблицу перемещений для всего бинарника.
Во-вторых - библиотеки одновременно используются в разных бинарниках, компилируемых по разным адресам.
Линкер, когда ведёт привязку кучи .rel и .lib знает как и что перемещать. Вопрос в том, как его заставить этим знанием поделиться в какой-то более-менее удобной форме.
Я ж не руками всё это обрабатывать буду. Всё скриптами.
SDCC для каждого из файлов исходников создаёт отдельный .lst файл. В нём все адреса относительные.
блин, попутал меня бес, не лст файл, map файл. там абсолютные адреса. вот от туда я беру адрес нужных таблиц и процедур/функций, когда нужно что-то проверить и отладить. если исходников несколько, но линкуешь их потом одной строкой в один бинарь, там все адреса, таблицы и функции/процедуры будут, в одном файле. хоть 10 исходников подрубай.
В мап-файл не пишутся объекты, которые static. То есть локальные, с областью видимости внутри С-файла.
Я нашел временный выход. Если ограничиться тем, что все перемещаемые модули лежат с адреса кратного 256, то меняются только старшие байты. И всё чики-поки:)
В принципе для модулей - более чем достаточно.
тут https://github.com/salextpuru/sdcc-noinit всё лежит.
Тест подгружаемого модуля - драйвера https://github.com/salextpuru/sdcc-noinit/tree/master/apps/test-mm128
Скрипты для генерации таблицы перемещений: https://github.com/salextpuru/sdcc-noinit/blob/master/scripts/make_reloc_tbl
Собственно библиотека с настраиваемым интерфейсом: https://github.com/salextpuru/sdcc-noinit/tree/master/libsrc/libmemman
Что получилось:
1. Автоматическая генерация интерфейса к библиотеке на основе .h файла.
2. Перемещаемый бинарь.
3. маленькая часть библиотеки (вызовы), вкомпиливаемая в основную программу.
Главное, что вся рутинная хрень по поводу генерации файлов - автоматизирована.
Дальше хочу, чтобы можно было вызывать библиотеки раскиданные по разным страничкам с запоминанием откуда вызвано и куда вернуться.
Видео. "Войны SDCC-NOINIT" :) https://hdd.tomsk.ru/file/rgxnkhlp
marinovsoft
17.05.2018, 09:20
https://openload.co/f/xGIEtbbpJss/sdcc-noinit.mp4
Вот буду в Кемерово - в гости зайду:)
marinovsoft
17.05.2018, 10:07
Залил на видеохостинг, чтобы другие могли посмотреть не скачивая.
В чём прикол сего "салюта"?
В чём прикол сего "салюта"?
Этот "салют" есть визуализация разработки по времени. Когда какой файл создан и кем (если разрабов несколько). Когда удалён. Конда изменён. И так далее.
В принципе, если проект большой, а разработчиков много - то очень красиво:)
- - - Добавлено - - -
Залил на видеохостинг, чтобы другие могли посмотреть не скачивая.
Да кто ж спорит) Спасибо)
SDCC 3.7.0
Ошибка
Пустой цикл while(1){} генерирует почемуто переход на какой-то левый адрес, а не зацикливается. Гадина такая. Полчаса потратил пока понял. :(
Oleg N. Cher
17.05.2018, 21:29
Дык тисни баг-репортик-то. А здесь зачем пишешь? Тут желающих обосрать SDCC даже больше, чем следует.
- - - Добавлено - - -
Баг-репорты наше всё!
Пишу чтобы те, кто на нем пишет знали.
Обосральщиков чего угодно везде полно:)
Oleg N. Cher
18.05.2018, 03:29
Это да...
Я сам пришёл к выводу, что вкладываться в средства разработки, которыми пользуешься, есть смысл. Даже не жалко на это времени - сделал полезный баг-репорт, а всем юзверям хорошо. И в тесты добавят, опять же.
Успокой меня, что таки сделал репорт =]
В мап-файл не пишутся объекты, которые static. То есть локальные, с областью видимости внутри С-файла.
Я нашел временный выход.
Чтобы найти не временный выход - надо ковырять линкёр, он работает с таблицей(ами) релокаций и ессно может создавать и сохранять её в файл. Так или иначе, тебе нужны сорцы sdcc линкёра для прикрутки данной фитчи.
Сорцы у меня есть. Они свободны. но я в них глянул и понял, что быстро сделать не получится. :) так что пока остаемся на "временном выходе" :)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot