У меня есть проект, над которым я работаю в vxWorks, создающий двоичный файл vxsim для тестирования. Процесс связывания состоит из трех этапов; соответствующие части make-файла выглядят примерно так:
partialImage.o: ${SYSTEM_OBJS} ${OBJS} version.o
ldsparc ${appropriate LDFLAGS go here} ${^} -o ${@}
# Don't ask me why they did it this way; it seems redundant to re-use
# all the other objects as well as partialImage.o, but I'm also not extremely
# versed in what's necessary for munch.tcl to do its thing.
ctdt.o: partialImage.o ${SYSTEM_OBJS} ${OBJS} version.o
${VXSIMNM} ${^} | tclsh ${path to munch.tcl} > ${@:%.o=%.c}
ccsparc ${appropriate CFLAGS go here} ${@:%.o=%.c} -o ${@}
${FINAL_IMAGE}: ${a list of dependencies here}
ldsparc -N -e _sysInit -Ttext 60010000 \
${appropriately ordered list of objects} \
-defsym _VX_DATA_ALIGN=16 \
-T link.RAM \
-o ${@}
Если необходима дополнительная информация (флаги и т.п.), дайте мне знать. Сейчас я не за этим компьютером, но через час я уточню этот вопрос с более подробной информацией, если к тому времени ответа не будет.
Ниже приведен примерный набросок сценария компоновщика. Если у вас есть доступ к vxWorks 6.x, это просто сценарий по умолчанию 'link.RAM':
START(_sysInit)
SECTIONS {
.text {
wrs_kernel_text_start = .;
/* A few other variable declarations and inclusions from various other segments */
. = ALIGN(16);
}
. = ALIGN(16);
/* The rest of the linker script */
}
Обратите внимание на тот факт, что wrs_kernel_text_start
происходит в начале текстового сегмента до того, как что-либо будет включено, и до любых операторов ALIGN.
В других проектах vxWorks, которые я делал, wrs_kernel_text_start = 0x60010000
; однако, в этом конкретном проекте это какой-то другой адрес примерно наравне с 0x6025XXXX
. Вы не ошиблись, адрес на 1 порядок выше ожидаемого, то есть это не 0x60025XXX
. _sysInit
начинается прямо в 0x60010000
, как я ожидаю.