Question

我有一个我正在vxWorks上工作的项目，构建一个用于测试的vxsim二进制文件。链接过程分为三个阶段; makefile的相关部分看起来大致如下：

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开始，正如我所料。

Answer 1

我打算删除这个问题，但我想有人可能会从答案中获得一些价值。 makefile ACTUALLY看起来像这样：

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

请注意，链接器脚本位于依赖项列表中，我将${^}作为输入文件之一包含在内。当我从依赖项列表中删除链接描述文件时，现在一切正常。

（vxworks）在使用此链接描述文件生成的二进制文件中，为什么遇到的第一个地址不是从文本段起始地址开始的？

1 个答案: