用C偏移量连接的NASM

我正在为C构建一个裸骨执行环境，通过引导加载程序引导。引导可执行文件运行良好，但我无法从C调用asm例程。我已经在ASM中定义了一个函数'putchar'，它应该可以从C调用。问题是，在调试所有对nasm的调用期间编译后的程序集看起来只有几个字节。用C偏移量连接的NASM

C源代码如下：

#include "io.h" 

void kmain() { 
    putchr('!', 5); 
    while(1); 
}

随着io.h：

extern void putchr(char c, int repeat);

此编译成：

│0x600 <kmain>   push 
│0x601 <kmain+1>   mov bp,sp 
│0x603 <kmain+3>   sub sp,0x18 
│0x606 <kmain+6>   mov WORD PTR [si+0x24],0x504 
│0x60b <kmain+11>  add BYTE PTR [bx+si],al 
│0x60d <kmain+13>  add bh,al 
│0x60f <kmain+15>  add al,0x24 
│0x611 <kmain+17>  and WORD PTR [bx+si],ax 
│0x613 <kmain+19>  add BYTE PTR [bx+si],al 
│0x615 <kmain+21>  call 0x625 ; Should be call to putchr 
│0x618 <kmain+24>  add BYTE PTR [bx+si],al 
│0x61a <kmain+26>  jmp 0x61a <kmain+26> ; I suppose this is while(1)

putchr在组件定义和调用另一个内部功能有：

bits 32 

global putchr 

    nop 
    nop 
    nop 
    xor eax, eax 
    nop 
    nop 

putchr: 
    ; PutChar expects: al = character (first arg), cx = repeat (second arg) 
    push ebp 
    mov ebp, esp 

    mov eax, [ebp + 8] ; First arg 
    and eax, 0xFF  ; Only interested in lower 8 bytes (8-bit al register) 

      ; Note at this point eax = 0xc3/195 and not 0x21/33 as I'd expect 

    mov cx, [ebp + 12] ; Second arg 
    call PutChar

的调用putchr是错误的，因为putchr不在0x625，但倒数第二个我的汇编文件的顶部nop是存在的。 putchr起始于0x627。我想这也是我无法读取传递的值的原因来自C.

我编译和链接如下（5“！”）：

nasm -f elf32 -F dwarf -g io.asm -o ../build/os/imm/asm/io.o 
gcc -ffreestanding -nostdlib -gdwarf-4 -m32 -ggdb3 -c kernel.c -o ../build/os/imm/c/kernel.o 
ld -m elf_i386 -nmagic -Tos.lds ../build/os/imm/c/kernel.o ../build/os/imm/asm/io.o -o ../build/os/os

随着链接脚本os.lds感相当基本的和直接的：

ENTRY(kmain); 

PHDRS { 
    headers PT_PHDR FILEHDR PHDRS; 
    code PT_LOAD; 
} 

SECTIONS { 
    .text 0x600: ALIGN(0x100) { *(.text) } :code 
    .data : { *(data) } 
    .bss : { *(bss) } 
    /DISCARD/ : { *(.eh_frame) } 
}

为什么会出现这种奇怪的0X2的偏移，为什么不能在功能参数从组件实现被拾起？

来源

2017-02-19 Sebazzz

快速浏览一下，您就可以混合使用16位和32位代码。你如何设法将'kmain'编译为16位并不明显？ – Jester

根据命令行参数（'-m32'），除汇编器文件中的位32外，所有内容都被编译为32位。 – Sebazzz

其实我认为你的'kmain'是32位，你只是将它错误地拆分为16位。现在的问题当然是，你用什么模式运行它？如果你还没有切换到32位保护模式，CPU将执行代码为16位，这是行不通的。 – Jester

我从来没有发现这个问题不幸，但我使用的是16位C，因为我想得到在摆弄了一段时间之后仍在工作。切换回32位我终于找到了问题：

mov esp, [stack]

设置esp堆栈的地址，而不是，我将其设置为堆栈值。 OSDev wiki并没有错，指出操作系统的开发可能会导致数小时的调试，然后才能在面前看到答案！

来源

2017-02-24 20:41:05 Sebazzz

用C偏移量连接的NASM

回答

相关问题