【问题标题】:What are these extra bytes in my binary file?我的二进制文件中这些额外的字节是什么?
【发布时间】:2012-07-22 00:44:36
【问题描述】:

我正在用 C 编写一个小型操作系统。我已经编写了一个引导加载程序,现在我正在尝试获取一个简单的 C 文件(“内核”)以使用 gcc 进行编译:

int main(void) { return 0; }

我使用以下命令编译文件:

gcc kernel.c -o kernel.o -nostdlib -nostartfiles

我使用链接器通过以下命令创建最终图像:

ld kernel.o -o kernel.bin -T linker.ld --oformat=binary

linker.ld文件内容如下:

部分 { . = 0x7e00; .文本对齐(0x00): { *(。文本) } }

(引导加载程序将映像加载到地址0x7e00。)

这似乎工作得很好——ld 生成一个 128 字节的文件,在前 11 个字节中包含以下指令:

00000000 55 推送 ebp 00000001 48 dec eax 00000002 89 E5 移动 ebp, esp 00000004 B8 00 00 00 00 移动 eax, 0x00000000 00000009 5D pop ebp 0000000A C3 RET

但是,我无法弄清楚其他 117 个字节的用途。拆卸它们似乎会产生一堆没有任何意义的垃圾。额外字节的存在让我想知道我是否做错了什么。

我应该担心吗?

【问题讨论】:

  • 哦,是的,我确实意识到生成的代码需要在保护模式下运行。引导加载程序将负责将 CPU 切换到保护模式。
  • @Aftnix:我正在生成一个平面二进制文件。应该没有 ELF 标头。
  • 之后怎么样:strip --strip-all -R .note -R .comment kernel.bin
  • 也许这是调试信息?尝试类似: ld kernel.o -o --strip-all kernel.bin -T linker.ld --oformat=binary

标签: c gcc operating-system kernel


【解决方案1】:

这些是额外的部分,没有被剥离也没有被丢弃。您希望您的 linker.ld 文件看起来像这样:

SECTIONS
{
    . = 0x7e00;

    .text ALIGN (0x00) :
    {
        *(.text)
    }

    /DISCARD/ :
    {
        *(.comment)
        *(.eh_frame_hdr)
        *(.eh_frame)
    }
}

我知道要从objdump -t kernel.o 的输出中丢弃哪些部分。

【讨论】:

    【解决方案2】:

    很简单,您使用的是 gcc,它总是在将控制权传递给您的 main 之前放置其初始化代码。 我不知道启动代码上有什么,但它们就在那里。正如您可能看到的,您的二进制文件中还有一个注释“GNU”,您无法使用 objdump -s -j 'section name' 打印特定扇区。

    【讨论】:

      猜你喜欢
      • 2017-08-25
      • 1970-01-01
      • 2018-07-20
      • 2021-12-07
      • 2013-02-18
      • 1970-01-01
      • 2015-02-17
      • 2013-11-09
      • 1970-01-01
      相关资源
      最近更新 更多