C内核编译：GCC-LD未定义对`uuuuu-main'；

因此，我尝试将一个C文件编译到.bin，然后在第一阶段引导加载程序之后将其添加到.img文件中。
我在该用户界面中找到了以下bash命令：

gcc-g-m32-c-ffreestanding-o kernel.o kernel.c-lgcc
ld-melf_i386-Tlinker.ld-nostdlib--nmagic-o kernel.elf kernel.o
objcopy-O binary kernel.elf kernel.bin

并使用以下C代码（取自同一答案，另存为kernel.C）：

/*链接器脚本将此代码放置在对象的开头*/
__asm_uuuu（“jmp主\r\n”）；
int main（）{
/*在这里做事*/
返回0；/*返回到引导加载程序*/
}

我在cygwin中执行了这些命令，结果如下：

ld: kernel.o: in function `main':
/cygdrive/d/Work/asm/kernel.c:4: undefined reference to `___main'
objcopy: 'kernel.elf': No such file

linker.ld

文件如下：

OUTPUT_FORMAT(elf32-i386)
ENTRY(_main)

SECTIONS
{
    . = 0x9000;
    .text : { *(.text.start) *(.text) }
    .data : { *(.data) }
    .bss  : { *(.bss) *(COMMON) }
}

我已经使用

objdump

分解了kernel.o文件，其结果如下：

> objdump -d -j .text kernel.o

kernel.o:     file format pe-i386


Disassembly of section .text:

00000000 <.text>:
   0:   eb 00                   jmp    2 <_main>

00000002 <_main>:
   2:   55                      push   %ebp
   3:   89 e5                   mov    %esp,%ebp
   5:   83 e4 f0                and    $0xfffffff0,%esp
   8:   e8 00 00 00 00          call   d <_main+0xb>
   d:   b8 00 00 00 00          mov    $0x0,%eax
  12:   c9                      leave
  13:   c3                      ret

我做错了什么？这是由cygwin引起的吗？如果是，我是否可以在windows上使用其他选项？（我试过MSVC，但那太可怕了）

---

另外，我的引导加载程序没有使用任何

.section

伪操作（我不知道如何正确地使用它们），这会不会在将来导致任何问题，并且它是否能正确地与编译的C程序一起工作？

通过深入搜索，可以很容易地发现

\u main

（内部有一个额外的下划线）是程序的实际入口点

以下两个答案也提到了同样的问题：

两者都要求某种形式的到

-lgcc

选项和libgcc库的连接

将

main

重命名为

\uu main

是可行的，但不建议这样做（内核的入口点显然是按照惯例

kmain

，如其他问答中所示）

\uu main

函数是操作系统在启动程序时调用的函数，它通常包含（例如）对

exit（）

的调用（如果返回类型为int，则从

main

传递返回代码）和一些其他底层系统调用（可能是特定于系统的，需要在此处进行更多研究）

---

GCC希望您甚至在独立编译中也包含一个

\u main

函数，因为它是所有应用程序的默认入口点（或者我看到人们声称的），因为您选择不使用交叉编译器，您必须处理windows命名约定的细微差别和其他奇怪之处。这适用于Cygwin和MinGW的本机Windows编译器。我的理解是，有了CygWin，它会寻找一个名为

\uuuuuu main

的入口点。您可能希望使用除

main

以外的其他方法来避免这种情况。尝试使用

kmain

，因为我相信编译器正在

main

中生成代码来调用

\uuuuuuu main

@MichaelPetch谢谢，在将main方法重命名为

\uuuuuu main

并适当设置跳转指令和linker.ld文件之后，您的理解确实是正确的，LD继续正确创建elf文件，请将此作为答案发布，以便我可以关闭此问题。

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/10/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0/configure --srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)