时间戳

首页 > 解决方案 > 在 C 代码中使用全局 NASM 符号时，Cygwin 上的 GCC 编译废话

assembly - 在 C 代码中使用全局 NASM 符号时，Cygwin 上的 GCC 编译废话

问题描述

我正在编写一个小型 64 位引导加载程序来探索汇编语言及其与 C 代码的交互。我正在用 NASM 编译汇编部分和 GCC 中的 C 部分，然后用 ld 链接在一起，并用 objcopy 提取纯代码。该代码旨在在没有 Grub 或任何其他引导加载程序的情况下运行：它将自身从软盘加载到内存中。目前，我正在研究 C 函数如何使用 NASM 中定义的符号，并且我正在努力做一些我认为“简单”的事情：

我在 NASM 中定义了一个全局变量，该变量位于自定义部分中。这样做的原因是我希望这个变量的虚拟地址在 > 0xffff800000000000 （内核空间）范围内。我正在处理我的链接描述文件中的寻址，见下文。该变量在汇编文件中定义如下：

    section .kdata    
    global xyz_foo_bar
    xyz_foo_bar:
        dq 0

在 C 代码中，我声明了一个只增加该全局变量的函数：

    extern unsigned long xyz_foo_bar;
    void test_xyz_inc() {
        xyz_foo_bar++;
    }

这已成功编译和链接 - 显然。但是，当我查看反汇编的功能时，我不明白我看到了什么。

    objdump.exe -M intel -d boot1.elf
    ...
    ffff800000008f73 <test_xyz_inc>:
    ffff800000008f73:       55                      push   rbp
    ffff800000008f74:       48 89 e5                mov    rbp,rsp
    ffff800000008f77:       48 8b 05 00 00 00 00    mov    rax,QWORD PTR [rip+0x0]        # ffff800000008f7e <test_xyz_inc+0xb>
    ffff800000008f7e:       48 8b 00                mov    rax,QWORD PTR [rax]
    ffff800000008f81:       48 8d 50 01             lea    rdx,[rax+0x1]
    ffff800000008f85:       48 8b 05 00 00 00 00    mov    rax,QWORD PTR [rip+0x0]        # ffff800000008f8c <test_xyz_inc+0x19>
    ffff800000008f8c:       48 89 10                mov    QWORD PTR [rax],rdx
    ffff800000008f8f:       90                      nop
    ffff800000008f90:       5d                      pop    rbp
    ffff800000008f91:       c3                      ret

地址 0xffff800000008f77：当我解释它试图取消引用没有位移的 RIP 并使用生成的 qword 作为 RAX 的输入时，我是对的吗？这有什么意义？我的猜测是编译器/链接器没有正确计算位移。

这是我编译代码的方式：

nasm -o boot1.o -l boot1.lst -f elf64 boot1.asm
gcc -ffreestanding -static-pie -c -mabi=sysv -Wall -o c_functions.o c_functions.c
ld -melf_x86_64 --build-id=none -static --unresolved-symbols=report-all -T boot1.ld boot1.o c_functions.o -o boot1.elf
objcopy -O binary boot1.elf boot1.bin

为了完整起见，这里是链接描述文件：

OUTPUT_FORMAT("elf64-x86-64");
/* We define an entry point to keep the linker quiet. This entry point
 * has no meaning with a bootloader in the binary image we will eventually
 * generate. Bootloader will start executing at whatever is at 0x07c00 */
ENTRY(main);
INCLUDE boot1-vars.ldinc;

SECTIONS
{
    . = load_offset;
    .text : {
        /* Place the code in boot1.o before all other code */
        boot1.o(.text);     
    }
    
    _text_end = .;
    
    . += code_virtaddr;
    .ktext : AT(_ktext_physStart) {
        _ktext_physStart = . - code_virtaddr;
        boot1.o(.ktext);
        c_*.o(.text);
    }
    .kdata : {
        boot1.o(.kdata);
    }
    . -= code_virtaddr;

    /* Place the data after the code */
    .data : AT(_data_physStart) {
        _data_physStart = .;
        *(.data);
        *(.rodata*);
    }

    /* Place the uninitialised data in the area after our bootloader
     * The BIOS only reads the 512 bytes before this into memory */
    .bss : SUBALIGN(4) {
        __bss_start = .;
        *(COMMON);
        *(.bss)
        . = ALIGN(4);
        __bss_end = .;
    }
    __bss_sizeb = SIZEOF(.bss);

    /* Remove sections that won't be relevant to us */
    /DISCARD/ : {
        c_*.o(.*);
    }
    
    _end = .;
}

我缺少什么基本的东西吗？

PE：boot1-vars.ldinc 的内容，根据要求：

load_offset = 0x7C00;
load_page = load_offset >> 12;
load_page_expand = load_page << 12;
pages_to_load = ((_end - load_page) >> 12) + 1;
sectors_to_load = ((_end - load_offset) >> 9) + 1;
mmap_special_page = load_page - 1;
mmap_special_page_virtaddr = mmap_special_page << 12;
mmap_special_page_pagetable = load_page - 2;
mmap_special_page_pagetable_virtaddr = mmap_special_page_pagetable << 12;
pmmalloc_special_page = load_page - 3;
pmmalloc_special_page_virtaddr = pmmalloc_special_page << 12;
pmmalloc_special_page_pagetable = load_page - 4;
pmmalloc_special_page_pagetable_virtaddr = pmmalloc_special_page_pagetable << 12;

mm_pml4_rm_segment = (load_page + pages_to_load) << 8;
mm_pml4_offset = 0;
mm_pml4_offset_0 = (mm_pml4_rm_segment << 4) + mm_pml4_offset;
mm_pml4_offset_1003 = mm_pml4_offset_0 + 0x1003;
mm_pml4_offset_2003 = mm_pml4_offset_0 + 0x2003;
mm_pml4_offset_3003 = mm_pml4_offset_0 + 0x3003;
mm_pml4_offset_4007 = mm_pml4_offset_0 + 0x4007;
mm_pml4_offset_5007 = mm_pml4_offset_0 + 0x5007;
mm_pml4_offset_6003 = mm_pml4_offset_0 + 0x6003;

/* kernel_stack_size = 0x2000; */

trap_div0_virtual = trap_div0;
trap_div0_virtual_16 = trap_div0_virtual & 0xffff;
trap_div0_virtual_shr16 = (trap_div0_virtual >> 16) & 0xffff;
trap_div0_virtual_shr32 = trap_div0_virtual >> 32;

trap_doubleFault_virtual = trap_doubleFault;
trap_doubleFault_virtual_16 = trap_doubleFault_virtual & 0xffff;
trap_doubleFault_virtual_shr16 = (trap_doubleFault_virtual >> 16) & 0xffff;
trap_doubleFault_virtual_shr32 = trap_doubleFault_virtual >> 32;

trap_invalidTSS_virtual = trap_invalidTSS;
trap_invalidTSS_virtual_16 = trap_invalidTSS_virtual & 0xffff;
trap_invalidTSS_virtual_shr16 = (trap_invalidTSS_virtual >> 16) & 0xffff;
trap_invalidTSS_virtual_shr32 = trap_invalidTSS_virtual >> 32;

trap_generalProtectionFault_virtual = trap_generalProtectionFault;
trap_generalProtectionFault_virtual_16 = trap_generalProtectionFault_virtual & 0xffff;
trap_generalProtectionFault_virtual_shr16 = (trap_generalProtectionFault_virtual >> 16) & 0xffff;
trap_generalProtectionFault_virtual_shr32 = trap_generalProtectionFault_virtual >> 32;

trap_pageFault_virtual = trap_pageFault;
trap_pageFault_virtual_16 = trap_pageFault_virtual & 0xffff;
trap_pageFault_virtual_shr16 = (trap_pageFault_virtual >> 16) & 0xffff;
trap_pageFault_virtual_shr32 = trap_pageFault_virtual >> 32;

trap_invalidSyscall_virtual = trap_invalidSyscall;
trap_invalidSyscall_virtual_16 = trap_invalidSyscall_virtual & 0xffff;
trap_invalidSyscall_virtual_shr16 = (trap_invalidSyscall_virtual >> 16) & 0xffff;
trap_invalidSyscall_virtual_shr32 = trap_invalidSyscall_virtual >> 32;

isr_spurious_virtual = isr_spurious;
isr_spurious_virtual_16 = isr_spurious_virtual & 0xffff;
isr_spurious_virtual_shr16 = (isr_spurious_virtual >> 16) & 0xffff;
isr_spurious_virtual_shr32 = isr_spurious_virtual >> 32;

isr_dummytmr_virtual = isr_dummytmr;
isr_dummytmr_virtual_16 = isr_dummytmr_virtual & 0xffff;
isr_dummytmr_virtual_shr16 = (isr_dummytmr_virtual >> 16) & 0xffff;
isr_dummytmr_virtual_shr32 = isr_dummytmr_virtual >> 32;

isr_userDummy_virtual = isr_userDummy;
isr_userDummy_virtual_16 = isr_userDummy_virtual & 0xffff;
isr_userDummy_virtual_shr16 = (isr_userDummy_virtual >> 16) & 0xffff;
isr_userDummy_virtual_shr32 = isr_userDummy_virtual >> 32;

tss_virtual = code_virtaddr + TSS;
tss_virtual_16 = tss_virtual & 0xffff;
tss_virtual_shr16_8 = (tss_virtual >> 16) & 0xff;
tss_virtual_shr24_8 = (tss_virtual >> 24) & 0xff;
tss_virtual_shr32 = tss_virtual >> 32;

标签： assemblygcccygwinx86-64nasm

解决方案

您正在使用-static-pie. 生成的代码将需要一个动态加载器来填充重定位条目。从GCC 文档：

-静态饼图

在支持它的目标上生成与静态位置无关的可执行文件。静态位置无关的可执行文件类似于静态可执行文件，但可以在任何地址加载而无需动态链接器。为了获得可预测的结果，您还必须在指定此链接器选项时指定用于编译的同一组选项（-fpie、-fPIE 或模型子选项）。

由于您最终生成的是二进制文件，因此所有重定位信息都消失了。我可以得出结论，您的引导加载程序不能是动态加载程序。它可能只是将二进制文件直接从磁盘读取到内存中。

如果您使用objdump -rd并查看 ，您会发现每次访问变量test_xyz_inc都有重定位条目。xyz_foo_bar当代码加载到内存中时，这些值通常由动态加载器修复。

您真正想要做的是生成非 PIC 静态代码。编译C文件时替换-static-pie为。我还建议在链接时删除，因为我相信您通过包含此内容来掩盖问题。我也相信你应该确保你没有用红色区域编译你的内核代码，所以我也建议额外的 GCC 选项。-fno-pic--unresolved-symbols=report-all-mno-red-zone

举个例子：

gcc -ffreestanding -static-pie -c -mabi=sysv -Wall -o c_functions.o c_functions.c

应该：

gcc -ffreestanding -fno-pic -mno-red-zone -c -mabi=sysv -Wall -o \
    c_functions.o c_functions.c

链接时，我建议更改：

ld -melf_x86_64 --build-id=none -static \
    --unresolved-symbols=report-all -T boot1.ld boot1.o c_functions.o -o boot1.elf

到：

ld -melf_x86_64 --build-id=none -static -T boot1.ld boot1.o c_functions.o -o boot1.elf

Cygwin 观察

在 OP 提到他们将 Cygwin 与 GCC 10.2 一起使用之后，我碰巧更新了我的 Cygwin 系统，我可以验证即使替换-static-pie为-fno-pic生成的代码是静态的，并且来自 RIP 的所有位移都设置为 0 并且链接器没有t 说有任何截断。尝试-mcmodel=large并没有解决问题。我没有时间调查为什么会发生这种情况，但这是使用 x86-64 或 i386/i686 ELF 交叉编译器进行 OS 开发问题较少的一个很好的理由。我建议在 Cygwin 中构建一个 x86-64 ELF 交叉编译器。有构建交叉编译器的一般准则在 OSDev 维基上。我没有尝试使用 Cygwin 进行这样的构建，所以我不确定是否有任何障碍使它比在 Linux 上构建更困难。

推荐阅读