如何解决汇编代码不同于gdb的代码显示
我正在从《操作系统从0到1》一书中学习操作系统,我试图在内核中显示名为main的代码,但是即使我跳到了GDB,显示在GDB中的代码也不一样。作为入口的地址。
bootloader.asm
;*************************************************
; bootloader.asm
; A Simple Bootloader
;*************************************************
bits 16
start: jmp boot
;; constants and variable definitions
msg db "Welcome to My Operating System!",0ah,0dh,0h
boot:
cli ; no interrupts
cld ; all that we need to init
mov ax,0x0000
;; set buffer
mov es,ax
mov bx,0x0600
mov al,1 ; read one sector
mov ch,0 ; track 0
mov cl,2 ; sector to read
mov dh,0 ; head number
mov dl,0 ; drive number
mov ah,0x02 ; read sectors from disk
int 0x13 ; call the BIOS routine
jmp 0x0000:0x0600 ; jump and execute the sector!
hlt ; halt the system
; We have to be 512 bytes. Clear the rest of the bytes with 0
times 510 - ($-$$) db 0
dw 0xAA55 ; Boot Signature
readelf -l main
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement,little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x600
Start of program headers: 52 (bytes into file)
Start of section headers: 12888 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 12
Section header string table index: 11
readelf -l main
Elf file type is EXEC (Executable file)
Entry point 0x600
There are 3 program headers,starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000000 0x00000000 0x00000000 0x00094 0x00094 R 0x4
LOAD 0x000000 0x00000000 0x00000000 0x00094 0x00094 R 0x4
LOAD 0x000100 0x00000600 0x00000600 0x00006 0x00006 R E 0x100
Section to Segment mapping:
Segment Sections...
00
01
02 .text
main.c
void main(){}
objdump -z -M intel -S -D build / os / main
Disassembly of section .text:
00000600 <main>:
void main(){}
600: 55 push ebp
601: 89 e5 mov ebp,esp
603: 90 nop
604: 5d pop ebp
605: c3 ret
但这是GDB的输出,方法是在主0x600处设置一个断点
0x600 <main> jg 0x647 │
│ 0x602 <main+2> dec esp │
│ 0x603 <main+3> inc esi │
│ 0x604 <main+4> add DWORD PTR [ecx],eax │
为什么会这样?我加载的地址错误吗?如何找到要加载的正确地址?
编辑: 这是编译代码;
nasm -f elf bootloader.asm -F dwarf -g -o ../build/bootloader/bootloader.o
ld -m elf_i386 -T bootloader.lds ../build/bootloader/bootloader.o -o ../build/bootloader/bootloader.o.elf
objcopy -O binary ../build/bootloader/bootloader.o.elf ../build/bootloader/bootloader.o
gcc -ffreestanding -nostdlib -fno-pic -gdwarf-4 -m16 -ggdb3 -c main.c -o ../build/os/main.o
ld -m elf_i386 -nmagic -T os.lds ../build/os/main.o -o ../build/os/main
dd if=/dev/zero of=disk.img bs=512 count=2880
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB,1.4 MiB) copied,0.0150958 s,97.7 MB/s
dd conv=notrunc if=build/bootloader/bootloader.o of=disk.img bs=512 count=1 seek=0
1+0 records in
1+0 records out
512 bytes copied,0.000127745 s,4.0 MB/s
dd conv=notrunc if=build/os/main.o of=disk.img bs=512 count=$((8504/512))
seek=1
16+0 records in
16+0 records out
8192 bytes (8.2 kB,8.0 KiB) copied,0.000184251 s,44.5 MB/s
qemu-system-i386 -machine q35 -fda disk.img -gdb tcp::26000 -S
和用于显示主代码的gdb代码;
set architecture i8086
target remote localhost:26000
b *0x7c00
set disassembly-flavor intel
layout asm
layout reg
symbol-file build/os/main
b main
解决方法
jg / dec esp / inc esi
是ELF幻数,不是机器代码!从ndisasm -b32 /bin/ls
的输出开始,您将看到相同的内容。 (ndisasm
始终将其输入视为纯二进制文件;它不查找任何元数据。)
7F 45 4C 46是0x7F字节之后的字符串"ELF"
,该字节是将文件格式标识为ELF的ELF幻数。在main
的实际机器代码之前,后面紧跟着更多的ELF标头字节。 objdump -D
会反汇编所有ELF节,但仍会解析ELF标头,而不像ndisasm
那样反汇编它们。因此,您仍然最终只能从.text
部分中看到代码,因为其他代码为空(因为您链接了该可执行文件而没有libc或CRT起始文件,并且使用C main作为ELF入口点?!?)
您将跳到ELF文件的开始,就好像它是纯二进制文件一样。并非如此,编写ELF程序加载器并不是那么简单。 ELF程序标头(readelf
可以解析)告诉您哪个文件偏移量位于哪个地址。 .text
节的开头将在文件中有些偏移,出于明显的原因,它们不会与ELF幻数重叠。 (尽管您可以找到适合它的方法,但它可能与ELF标头重叠:http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html)
然后,按照程序标头中的说明将文件映射到内存后,您将跳转到ELF入口点地址(对于您的情况为0x600)。 (通常不是功能,在Linux之类的真实操作系统下,您不能从入口点ret
。而是需要进行出口系统调用。)您可以还是在这里,因为您jmp
而不是call
。
这就是_start
与main
分开的原因;用编译器生成的main
作为入口点来构建程序不起作用。
当然,大多数努力都是注定要失败的,因为您在CPU仍处于16位实模式的情况下跳到了主系统。但是您的主程序是为32位模式编译/汇编的。您可以使用gcc -m16
来解决该问题,以便在必要时使用操作数大小+地址大小前缀来组合16位模式的gcc输出。
不执行任何操作的主设备的机器代码实际上将在16位和32位模式下均有效。如果您使用了return 0
而不进行优化,则不是这种情况:mov eax,imm32
的操作码(不带前缀)暗含了不同的指令长度,具体取决于CPU对其进行解码的方式,因此在16位模式下进行解码将写入AX并保留2个字节的零。
最可能最简单的方法是将“内核”转换为平面二进制文件,而不是在引导加载程序中编写ELF程序加载程序。请遵循osdev教程,因为很多事情可能出错,例如,您必须注意静态数据。
或者请参见How to make the kernel for my bootloader?,获取示例引导程序,该示例引导程序在切换到32位保护模式后调用C函数 。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。