ics2017pa1.RTFSC

ics2017pa1.RTFSC

Init_monitor的位置讲义中已经给出:

1

2

3

如果命令行个数比较多时，如果按照顺序一个一个定义参数含义很容易造成混乱，而且如果程序只按顺序处理参数的话，一些“可选参数”的功能将很难实现，这个问题在 linux 中用 getopt 等函数可以优雅地解决。
.html

可以从讲义找到下面语句的位置debug目录下：

.html

再回到原来的ui_mainloop函数上

结合之前的使用，不难分析出能看出这是一个类似于图灵机的C语言实现：不断地修改eip指针（IP），从而从虚拟的内存中取出命令，并解析，从cmd_table中寻找匹配项目，如果是错误的命令就给出提示（“Unknow command”）。

我们再来看问题

首先在讲义中可以找到这条指令的位置

搜索这个函数

因为unit64是无符号数，所以-1被解释为最大的无符号数（推导见袁阿姨的书），所以指令将被执行最大次数（这是在is_batch_mode==true的情况下，也是就是一开始在monitor的解析函数下，输入了-b）

具体批处理是啥，我们就先不管了哈哈。

然后是前面的一个寄存器写作题目:

下面是上述的结构体定义

先来看一下报错的申明

是reg_w调用错误，查看结构体，发现函数（reg.h）定义如下

再来看报错的位置(reg.c)

好吧，我承认我什么都没看出来（希望会的大佬能指点我一下，谢谢）
那就老老实实按照改吧
“32位、16位、8位寄存器物理上并非独立的，所以将其包含在同一共用体中
32位寄存器eax,ebx,ecx,edx,esp,esi,edp,edi之间相互独立，所以包含在同一结构体中
gpr与eax,ebx,ecx,edx,esp,esi,edp,edi都表示寄存器，所以指向同一内存地址，包含在一个共用体中
eip与寄存器与通用寄存器相互独立，所以最终包含在同一结构体中”
回顾一下pa1的前面所说的i386寄存器

按照这个思路改一下

编译成功!

再回到之前我们看到的reg_test()上

比如说，就是随即生成数，扔到regsl和regw中，检验eax的低十六位是否等于ax中的值。
&0xffff的作用就是取低十六位，懒得证明了，就贴个图，袁阿姨也讲过：

再看下一题


让我们在该目录下搜索，发现了如下的数组定义：

然后我们再查看opcode_entry是什么

Opcode的中文是指令
我们还可以发现，在opcode数组中出现了一些该C文档中的宏定义：
![在这里插入图片描述](https://img-
blog.csdnimg/20191014184526507.png)

全局再搜索concat函数，得到：

好了，再纠结我也看不懂了，也不想补习C，等到要用到这个知识的时候再看吧。

来康康

然后我再monitot的debug目录下找到使用它的地方

以后估计可以用这个憨憨函数。
下面是Assert的定义：

下面是panic的定义：

他们的使用案例：