找不到GRUB Multiboot标头

本文介绍了找不到GRUB Multiboot标头的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

阅读此此问题，它是主要答案，我在内核上运行 readelf，注意到我的 .text 部分在 0x00101000 而不是 0x00100000.我还注意到上面的部分显示为.not.gnu.build-i，该位置应该位于.text部分.有没有一种方法可以使我的.text节放置在正确的位置?我已经使用 align 4 将其设置为1M.

After reading this this question and it's primary answer, I ran readelf on my kernel, and noticed my .text section was at 0x00101000 and not 0x00100000. I also noticed a section above that read .not.gnu.build-i that was in the place the .text section is supposed to be. Is there a way I could make my .text section be in the correct place? I have already used align 4 to set it to 1M.

推荐答案

问题是 LD (或 LD 通过 GCC )自动在前4k中放置一个便笺部分(如果已生成).如果将最终的内核与 GCC 链接，则将其传递给 -Wl，-build-id = none 选项.如果直接使用 LD 链接最终二进制文件，则可以将其传递给-build-id = none .

The issue is that LD (or LD via GCC) is automatically placing a notes section (if one was generated) in the first 4k. If linking the final kernel with GCC pass it the -Wl,--build-id=none option. If you are using LD directly to link the final binary then you can pass it --build-id=none .

如果编写多重引导 ELF 对象，则此额外部分的存在可能会迫使mulitboot标头超过文件中的8k位置.这是因为 ELF 标头通常占用文件前4k的最小值.现在，将 .note.gnu.build-id 和 .multiboot 部分的4k添加到物理文件的8k标记之外.这将导致像GRUB这样的多重引导加载程序认为您的 ELF 可执行文件没有多重引导标头，因为它只能浏览文件的前8k.

If writing a multiboot ELF object the existence of this extra section can force the mulitboot header beyond the 8k position in the file. This is accounting for the fact that ELF headers usually take a minimum of the first 4k of the file. Add in the 4k for .note.gnu.build-id and .multiboot section is now beyond 8k mark of the physical file. This will cause a multiboot loader like GRUB to think your ELF executable doesn't have a multiboot header since it only looks through the first 8k of the file.