(vxworks) Почему в двоичном файле, созданном с использованием этого сценария компоновщика, первый встреченный адрес не начинается с начального адреса текстового сегмента? - PullRequest
1 голос
/ 03 августа 2011

У меня есть проект, над которым я работаю в 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, как я ожидаю.

1 Ответ

0 голосов
/ 03 августа 2011

Я собирался удалить вопрос, но я полагаю, что кто-то там может получить какую-то ценность из ответа.Makefile на самом деле выглядел так:

outfile: ${SYSTEM_OBJS} ${OBJS} version.o link.RAM
    ldsparc ${appropriate LDFLAGS go here} ${^} -o ${@}
(...)

Обратите внимание, что скрипт компоновщика был в списке зависимостей, и я включил его с ${^} в качестве одного из входных файлов.Когда я удалил скрипт компоновщика из списка зависимостей, теперь все выглядит нормально.

...