操作系统真相还原--第七章中断实验BUG--找不到中断向量表

本文主要是介绍操作系统真相还原--第七章中断实验BUG--找不到中断向量表，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、问题描述

在进行第七章中断实验时，出现一个问题。当使用lidt加载中断向量表命令后，使用bochs的调试命令Info idt，发现中断号对应的中断函数地址有问题：
在这里插入图片描述
从图中可以看到，DPL正确，选择子正确，但是基址有问题，全为0

二、解决思路

先说结论：问题出现在lodaer.S中，在加载elf文件的program段时，只运行了一次加载过程，导致只加载了.text段，也就是代码段，没加载.data段。

2.1 尝试从编译命令层面解决

完成该实验时ubuntu的gcc版本为7.5，根据有的博主描述，需要降版本到4.4，于是进行降版本，参考文章：

《操作系统真象还原》第五章 ---- 轻取物理内存容量启用分页畅游虚拟空间力斧直斩内核先劈一角闲庭信步摸谈特权级

并深入学习了nasm编译和ld链接的原理，以为是链接出现了问题，于是修改编译命令，最终使用的编译命令如下：

#var for boot#Var for GCC
# 此处可能需要加stck_protect那个编译选项
CFLAGS += -fno-builtin 
INCLUDE := \-Ikernel/ \-Iinclude/ \-Ilib/ \-Ilib/kernel/ \-Ilib/kernel/include
GCC32 += -m32
GCC_MARCH += -march=i386#Var for ld
BUILD_SRC := build/main.o \build/init.o \build/interrupt.o \build/print.o \build/kernel.o
BUILD_DES := build/kernel.bin
LD_ENTRY_ADDR := -Ttext 0xc0001500
LD_ENTRY_FUNC := main#Var for gene
CURRENT_PATH := $(shell pwd)
_all:all: _all@echo "==========================start building...===================================="@echo "=============================#1 start compile=============================="gcc ${GCC32} ${INCLUDE} -c ${CFLAGS} -o build/main.o kernel/main.cnasm -f elf -o build/print.o lib/kernel/print.Snasm -f elf -o build/kernel.o kernel/kernel.Sgcc ${GCC32} ${INCLUDE} -c ${CFLAGS} -o build/interrupt.o drivers/interrupt/interrupt.cgcc ${GCC32} ${INCLUDE} -c ${CFLAGS} -o build/init.o init/init.c@echo "=============================#2 start ld=================================="ld -m elf_i386 ${LD_ENTRY_ADDR} -e ${LD_ENTRY_FUNC} -o ${BUILD_DES} ${BUILD_SRC}dd if=${CURRENT_PATH}/${BUILD_DES} of=${CURRENT_PATH}/hd60M.img bs=512 count=200 seek=9 conv=notrunc@echo "build successful!"@echo "objdump..............."objdump -d build/kernel.bin > build/asm/kernel.bin_gcc_4.4.7.asm

第七章实验的文件结构如下，大致仿照linux的结构来建立的文件夹：
在这里插入图片描述
然而，此阶段并没有解决问题，仍然存在该问题。

2.2 反汇编kernel.bin分析原因

上一步没有结果，反复对照各博主实验过程与《操作系统真相还原》书中给出的代码，可以保证C代码和汇编代码kernel.S没有任何问题。于是反汇编kernel.bin，分析问题。通过gcc的反汇编工具objdump来反汇编：

objdump -d build/kernel.bin > build/asm/kernel.bin_gcc_4.4.7.asm

结合interrupt.c中的C代码：

interrupt.c:
/*创建中断门描述符*/
static void make_idt_desc(struct gate_desc* p_gdesc,uint8_t attr,intr_handler function){p_gdesc->func_offset_low_word=(uint32_t)function & 0x0000ffff;p_gdesc->selector=SELECTOR_K_CODE;   // 中断后进入内核代码p_gdesc->dcount=0;p_gdesc->attribute=attr;p_gdesc->func_offset_high_word=((uint32_t)function & 0xffff0000)>>16;
}/*初始化中断描述符表*/
static void idt_desc_init(void){int i;for (i=0;i<IDT_DESC_CNT;++i){make_idt_desc(&idt[i],IDT_DESC_ATTR_DPL0,intr_entry_table[i]);}put_str("   idt_desc_init done\n");
}

定位汇编中的问题命令：
在这里插入图片描述
可以看到，中断向量函数基址作为函数调用的第三个参数，被赋值给了eax并进行压栈。在此处打断点并查看eax寄存器的值，发现为0。说明此处没有把中断处理函数基址赋值给eax寄存器。

此处令我疑惑，不可能找不到中断处理函数基址，因为链接已经成功了，可以看到反汇编后的代码中有这些中断处理函数：
在这里插入图片描述
此处未能发现问题，主要是汇编代码太多了，不容易分析问题。于是做了一个简单的实验，来分析gcc编译文件与nasm编译文件的链接问题

2.3 制作test文件验证链接是否存在问题

制作main_test.c:

#include "stdint.h"
typedef void* intr_handler;
extern intr_handler intr_entry_table[0x21];
void main(void) 
{uint32_t test_low = (uint32_t)intr_entry_table[0] & 0x0000ffff;uint32_t test_high = ((uint32_t)intr_entry_table[0] & 0xffff0000)>>16;while(1); 
}

制作kernel_test.S:

[bits 32]
[section .data]
global intr_entry_table
intr_entry_table:%macro VECTOR 1
[section .text]intr%1entry:                ;每个中断处理程序都要压入中断向量号，一个中断类型一个中断处理程序out 0xa0,al              ;向从片发送iret                     ;从中断返回
[section .data]dd intr%1entry           ;存储各个中断入口程序的地址，形成intr_entry_table数组
%endmacroVECTOR 0x0
VECTOR 0x1
VECTOR 0x2
VECTOR 0x3

编译链接命令：

debug: _all@echo "==========================Debug...===================================="gcc ${GCC_MARCH} ${GCC32} ${INCLUDE} -c ${CFLAGS} -o debug/build/main_test.o debug/main_test.cnasm -f elf -o debug/build/kernel_test.o debug/kernel_test.Sld -m elf_i386 ${LD_ENTRY_ADDR} -e ${LD_ENTRY_FUNC} -o debug/build/kernel_test.bin debug/build/main_test.o debug/build/kernel_test.o  objdump -d debug/build/kernel_test.bin > debug/build/asm/kernel_test.bin.asmobjdump -d debug/build/kernel_test.o > debug/build/asm/kernel_test.o.asmobjdump -d debug/build/main_test.o > debug/build/asm/main_test.o.asmdebug_dd: _alldd if=${CURRENT_PATH}/debug/build/kernel_test.bin of=${CURRENT_PATH}/hd60M.img bs=512 count=200 seek=9 conv=notrunc

对kernel_test.bin进行反汇编，结果如下：
在这里插入图片描述
想说的都在汇编中加了注释了，关键就是0xc000252c这个地址中的数据，是不是intr0x0entry的起始地址，也就是是不是0xc0001520。但是在反汇编之后的文件中根本没找到0xc000252c这个地址，这也很让我疑惑。

将该kernel_test.bin载入bochs中运行，使用xp/2 0x252c(实地址，对应虚拟地址0xc000252c)，查看0xc000252c这个地址中的数据，发现全是0。这个时候想起来了，在kernel.S中，把中断函数的地址，存在了data段中。所以说0xc000252c这个地址，应该是data段的地址。于是解析kernel_test.bin这个elf文件：
在这里插入图片描述
发现确实是data段在内存中的首地址，所以只要看一眼data段的首地址的内容(文件内偏移0x052c)，就能确定是不是编译链接有问题了。通过16进制打开kernel_test.bin文件：

发现0x052c地址(对应虚拟地址0xc000252c)中是有内容的，并不是0，而且就是c0001520，也就是第0个中断处理函数的地址：
在这里插入图片描述
至此可以确定，编译没有问题，出问题的是data段的加载有问题，可能根本没有加载进来，也可能加载到了错误的位置。