Question

编辑：我完全重述了我原来的问题，因为它远非清晰（在底部可以看到它的不清晰！）。

我正在开发一个RTOS，其中内核和应用程序必须映射到内存中非常特定的位置。例如：

0x00000000:0x0000ffff: application #1
0x00010000:0x0000ffff: application #2
...
0xffff0000:0xffffffff: kernel

分别开发（和编译）应用程序（和内核）。要将所有内容合并为单个可执行文件，请使用以下过程：

（另外）编译内核和应用程序（删除任何符号）。
（通过脚本）生成链接描述文件，将内核和应用程序重定位到所需位置。为防止部分名称之间发生任何冲突，生成的链接描述文件将“重命名”所有应用程序的所有部分（例如.app1.text，.app1.data，.app1.bss，...）。
使用以前生成的链接描述文件链接（即全部合并）。

问题1）是否可以用以下过程替换步骤＃2和＃3？

将内核和应用程序的目标文件重定位到所需位置。
重命名应用程序对象文件上的所有符号（以防止名称冲突）。
合并所有。

我正在尝试用一些已经可用的工具替换链接器脚本的生成。

步骤＃1应该可以通过创建与位置无关的可执行文件来实现（我仍然需要对此进行调查）。

步骤＃2可以通过 GNU objcopy 。

对于第3步，我还没有可能的解决方案。如果使用 GNU ld ，它将使用一些默认的链接描述文件，并且之前的重定位将丢失。如果 GNU gdb 接受从 GNU ar 生成的归档，问题就会得到解决（我猜！）。

问题2）如果可以进行上述过程，是否也可以应用于调试信息？

步骤＃1应保持不变。

对于步骤＃2，我不确定是否重命名调试信息。

第3步的问题仍然存在。

原始问题如下：

我有一个自定义内核和一个或多个应用程序，我想使用   GDB调试整个系统。为了避免任何名称冲突   在链接期间，我使用objcopy重命名所有的部分和符号   名称（应用程序的起始地址在内核中是硬编码的）。   但是，调试信息[我猜]在那些内部进行了硬编码   .debug。*部分，不要重命名。

有没有办法重命名调试信息？在那之后，   将该信息与另一组已存在的调试合并   信息？

我搜索了GCC的手册，看看我是否能找到一个前缀选项   （比如全局命名空间）编译期间的所有符号，但是我   还没找到。

我的猜测是有一种暴露它的调试格式   有关对象符号表的信息（可以重命名）。

Answer 1

回答问题1）

步骤＃1应该可以通过创建一个职位来实现独立可执行文件（我仍然需要对此进行调查）。

不，这是不可能的。当仅在加载时知道可执行文件的加载地址时，与位置无关的可执行文件很有用。在我的情况下，我想硬连线加载地址。

对于第3步，我还没有可能的解决方案。如果使用GNU ld，那就是使用一些默认链接描述文件，以前的重定位丢失。如果GNU gdb接受了从GNU生成的归档，问题就会出现要解决（我猜！）。

似乎没有解决方法。因此必须使用链接描述文件。

回答问题2）

对于步骤＃2，我不确定是否重命名调试信息不

实际上，调试信息不会被重命名。您可以使用 objdump -s 并检查调试信息是否在 .debug。* 部分中进行了硬连线。

解决方法）

即使没有调试信息，您也可以使用目标文件的符号表来设置断点。但是，相反， b main 必须使用 b * main ，因为symtable中的符号被解释为地址。这并不多，但肯定有帮助。

如何重命名调试信息？

1 个答案: