ARV 1 2 февраля, 2019 Опубликовано 2 февраля, 2019 · Жалоба Подскажите, кто знает, почему я не могу получить значение символа, заданного в скрипте линкера? Скрипт (фрагмент): Цитата .text : { *(.vectors) KEEP(*(.vectors)) /* For data that needs to reside in the lower 64k of progmem. */ *(.progmem.gcc*) /* PR 13812: Placing the trampolines here gives a better chance that they will be in range of the code that uses them. */ . = ALIGN(2); __trampolines_start = . ; /* The jump trampolines for the 16-bit limited relocs will reside here. */ *(.trampolines) *(.trampolines*) __trampolines_end = . ; /* avr-libc expects these data to reside in lower 64K. */ *libprintf_flt.a:*(.progmem.data) *libc.a:*(.progmem.data) *(.progmem*) . = ALIGN(2); /* For future tablejump instruction arrays for 3 byte pc devices. We don't relax jump/call instructions within these sections. */ *(.jumptables) *(.jumptables*) /* For code that needs to reside in the lower 128k progmem. */ *(.lowtext) *(.lowtext*) __ctors_start = . ; *(.ctors) __ctors_end = . ; __dtors_start = . ; *(.dtors) __dtors_end = . ; KEEP(SORT(*)(.ctors)) KEEP(SORT(*)(.dtors)) /* Внедрение моих секций для таблиц */ __my_tbl_start = __dtors_end ; *(.my_table) __my_tbl_end = . ; KEEP(SORT(*)(.my_table)) /* Конец моих секций для таблиц */ То есть определил два символа __my_tbl_start и __my_tbl_end В программе делаю так: extern int __my_tbl_start; extern int __my_tbl_end; printf("%04X %04X", __my_tbl_start, __my_tbl_end); И получаю 0x0000 0x0000, хотя в map-файле эти символы нулю, естественно, не равны: Цитата 0x0000069e __my_tbl_start = . *(.my_table) .my_table 0x0000069e 0x2 ./alarm-main.o 0x0000069e _A0_DATA28 .my_table 0x000006a0 0x2 ./alarm.o 0x000006a0 _A0_DATA22 .my_table 0x000006a2 0x2 ./timers.o 0x000006a2 _A0_DATA121 0x000006a4 __my_tbl_end = . SORT(*)(.my_table) Что я делаю не так? Как в программе получить значения этих символов дл доступа к моей таблице? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 78 2 февраля, 2019 Опубликовано 2 февраля, 2019 · Жалоба а чему же равно &__my_tbl_start и &__my_tbl_end Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 1 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба Тому, что надо :) Ночью приснилось, что надо проверить адрес этих объектов - и да! он оказался верным. Но по-моему, это какой-то грязный хак... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 78 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба Ну почему грязный? линкер определяет ГДЕ что лежит, содержимое - не его забота. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GeorgK 1 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба Если посмотреть исходники загрузчика - так это совершенно нормальная практика - файл lds: /* Сегмент исполняемого кода */ . = ALIGN(4); .text : { uboot_start = .; *(.text) } text_end = .; * * * /* Сегменты неинициализированных данных */ . = ALIGN(4); .sbss : { *(.sbss*) } .bss : { *(.bss*) . = ALIGN(4); } .scommon : { *(.scommon*) . = ALIGN(4); } /* Окончание неинициализированных данных */ uboot_end = .; где-то в программе: /* Занимаемая загрузчиком область памяти */ ulong len = (ulong)&uboot_end - (ulong)&uboot_start; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться