无知的我

关于GDB的remote stub，这两天又有了一些新的认识：

1. 在ARM上，并不是所有的无法识别的指令都是未定义指令，譬如我前面写的那些指令，并不会导致未定义指令的异常。通过对GDB的一些观察，GDB使用如下 数字作为未定义指令: BEBE、E7FFDEFE。通过实验，可以确定，它们在VBA中会导致undefined中止，而之前的只是无法反汇编，不会导致中止。

2. 在GDB的remote调试中，设定断点的工作可以由GDB代劳，只要返回不能识别Z指令，则GDB会自动地使用写内存的方式设定断点。这样remote stub就可以非常简单，处理尽量少的指令。由于没有试过在Z指令时返回OK，我估计如果在Z指令时返回OK，则GDB会把设定断点的工作完全交给 remote stub，这样就可以用软中断的方式了。

到目前为止，关于GBA的undefined instruction的实验我已经做了很多次，在数次实验和不断google之后，我现在基本得出一个结论：在GBA上要使用undefined instruction，是需要一个专门的设备叫做DACS的。而普通的卡带是没有这种设备的，因此当GBA发生了undefined instruction之后会死机，而不是执行ROM上的内容。我不知道我的猜想是否正确，但至少在MappyVM上可以正确使用的程序烧到卡带上就不行 了。

因此，关于调试，就需要换新的方法了，目前可选的方法有以下几种：

1. SWI：在GBA上，由于BIOS已经完全占用了软中断，因此必须要使用一些特殊的技巧，譬如使用RAM中的某个位置作为软中断的向量。用软中断，应该可以调试各种程序。缺点是对程序可以使用的内存做出了限制，这导致使用者必须仔细地设定内存的使用方式。

2. 跳转：通过b或者bl指令跳转到指定的位置。如果使用b指令，则可以通过跳转到的不同位置来确定不同的断点，如果是bl指令，则在跳转后可以直接得到原先 的位置。这种调试方法的问题在于如果使用thumb模式，很多代码将无法调试，因为一个16位的thumb指令无法随意表达跳转的位置。即便是ARM模 式，也比较麻烦。

3. 在编译完成之后，在可执行代码中加入空代码：使每个指令之间的距离加大，从而可以加入更多的内容以便添加的断点。问题是必须要搞明白elf和调试信息的格式，只修改代码部分，修改完毕后，还需要修改各种调试信息的内容。

从上面三种情况来看，第一种是比较方便实现的，第三种是功能最强大的。

D-Link DI 724P+ 无线路由支持网络打印机，这个网络打印机实际上就是一个 LDP 的服务器，因此，在 Linux 上，通过 CUPS 直接添加打印机就可以了，在选择打印机位置的时候，填写 lpd:///lp。

当PyGTK升级到2.4之后，不知是我的错误还是PyGTK的bug，很多与多线程有关的调用都发生了错误。这两天，我花了很多时间来修改coralftp中关于线程的问题，现在总结一下。

PyGTK是可以支持多线程的，在多线程程序的头部，必须有一个gtk.threads_init()调用，否则程序会运行地出奇地慢并伴随各种错误。

PyGTK 多线程的编程一般有两种模型，一种是通过gtk.threads_enter()和gtk.threads_leave()来进入和退出临界区，一遍让多 个线程顺序地访问GTK的资源。在这种模型下，需要搞清楚PyGTK合适自动进入临界区，何时不会自动进入。比较麻烦的是当响应GUI事件的方法时，会自 动进入临界区，但在响应idle_add、timeout等事件时则不会，因为有时很难判断一个函数究竟是由idle_add调用的还是响应了某个事件。 即便可以判断，这种方式也是比较麻烦的，因为对于有大量界面工作的程序而言，想要每一次都正确地进出临界区，可能要写大量的代码。而调试也是这类程序的麻 烦。

另一种方法是只在主线程中使用GTK的资源，其他的线程则通过gtk.idle_add()的方式来执行访问GTK资源的函数。这种方法相对于上一种而言，是容易了很多了，但也有一些需要特别注意的地方。
1. 由于在主线程中也没有使用临界区，所以在编程过程中是不能使用临界区的，即这种方法不能和第一种混淆。
2. gobject有事件的机制，其事件机制是可以在其他的线程中使用的，并且，当通过emit触发事件时，事件的响应程序是在触发事件的线程中运行的，而不 是在主线程或GTK线程中运行的。因此响应事件的函数如果希望在主线程中运行，仍然需要使用gtk.idle_add()。
3. GTK的timeout和监控文件流的机制最好不要在非GTK线程中使用，虽然理论上它们应该是可用的。这两个东西完全可以用Python的threading.Timer和select.poll()来代替。
4. 在通过idle_add运行的函数中，是不能使用Dialog的run()方法的，否则也会造成死锁。Dialog的run()方法可以用show()和 set_modal(True)来代替，并且通过编写一个响应’response’事件的函数在必要的时候执行其destroy()方法就可以了。

虽然还是有一些小的bug，但Python + GTK2仍不失为一个强大的组合：GTK2的pretty加上Python的powerful、flexibe，我们完全可以用它们编写出功能强大、界面友好、运行快速的桌面应用程序。

ECB是Emacs的代码浏览器，它支持多种程序设计语言，可以让用户方便地查看文件夹中的程序，和程序中的对象结构。在Debian上，可以直接安装这个软件包，如果要让它支持Java，还要安装JDE。

启 动ECB后，它会将Emacs窗口分成几个子窗口，在不同的子窗口中可以看到不同的内容。通过鼠标，可以方便地在子窗口之间切换和操作。如果要使用键盘， 就需要记住一些常用的组合键。对于ECB，组合键都是以“C-c .”开始的，如果是跳转到窗口，则后面按”g”加上窗口的缩写。另外ECB的窗口布局也是可以修改的，ECB中已经有多种常用的窗口布局可供选择，要临时 切换窗口布局可以按”C-c . l c”，并输入布局的名称，也可以按”C-c . l t”在几个预先设定好的布局之间切换。

在Windows上，ECB还可以用图片表示目录、文件、方法等等内容，但目前的Linux版本似乎还不能很好地支持这一点，不过即便使用普通的文本方式，通过一系列的符号和颜色，也已经够清楚了。

有了ECB，Emacs就成了一个更加强大的IDE啦。

今天在看DocBook slide的时候发现原来Mozilla已经可以很好地支持MathML，但必须安装一些字体。我试了一下，在我的debian sid上，必须安装的字体有三种：

1. latex-xft-fonts: 这是一个标准的debian软件包，直接安装就可以了；
2. Mathematica 4.1 fonts: 需要从Mathematica的网站下载4.1版本的字体，将字体解压到/usr/share/fonts/truetype/mathematica目录中就可以了；
3. Symbol: 虽然机器上已经有了这个字体，但其名称是Standard Symbol L，因此，最简单的方法是使用Adobe Acrobat Reader中的Symbol字体，只要创建一个目录/usr/share/fonts/type1/acroread，并符号链接 /usr/lib/Acrobat5/Resource/Font中的字体到这个目录中就可以了。

完成之后，执行一下fc-cache; fc-list，应当可以找到Math*和Symbol字体了。

重新启动mozilla/firefox，找个有MathML的页面试试看吧。