MIPS binutils-2.17和gcc-3.3.6一起正常编译的方法

前面写过了binutils-2.17可以和gcc-3.4.6一起正常编译，不过既然我已经为了让binutils-2.17和gcc-3.3.6费了不少劲，干脆也介绍一下。

不能一起编译的原因主要是binutils-2.17中mips部分将DIFF_EXPR_OK以及相关的东西都给去掉了，这样一个section中的符号被另一个section引用会产生问题，最终在binutils-2.17/gas/expr.c 1877行出错。而 gcc-3.3.6中的libgcc2.c恰巧会产生一个section中的符号被另一个section引用的MIPS代码。而binutils-2.15能根其一起编译的原因很简单，DIFF_EXPR_OK以及相关的代码都在。

具体解决方式为：
binutils-2.17 /gas/config/tc-mips.h
在165行加入
#define UNDEFINED_DIFFERENCE_OK
binutils-2.17/gas/expr.c
1873行
#ifdef DIFF_EXPR_OK
换为
#if ((defined DIFF_EXPR_OK) || (defined TC_MIPS))
这样再编译就可以让gcc-3.3.6正常编译了。

当然具体有啥后果我就不好说了，呵呵。

binutils-2.17竟然能跟gcc-3.4.6一起用

前几天还提过binutils 2.17跟gcc-3.3.6不能一起编译的问题，俺明明记得俺后来用gcc-3.4.6也测试过有同样的问题，然后就换成了binutils-2.15没再弄。

今天俺突然来了兴致，决定解决一下这个问题顺便发到maillist上。找到了出问题的原因(发完这个日志一会单独写个日志介绍)， 胡乱改了一下发现binutils-2.17能和gcc-3.3.6一起编译了，于是准备发帖子到MAILLIST。为了表示测试的充分，俺特地弄出gcc-3.4.6一起编译看看，竟然发现我没改过的binutils也能跟gcc-3.4.6一起编译，早知道这样我折腾啥呢？晕！

MIPS binutils-2.17和gcc-3.3.6一起正常编译的方法

前面写过了binutils-2.17可以和gcc-3.4.6一起正常编译，不过既然我已经为了让binutils-2.17和gcc-3.3.6费了不少劲，干脆也介绍一下。

不能一起编译的原因主要是binutils-2.17中mips部分将DIFF_EXPR_OK以及相关的东西都给去掉了，这样一个section中的符号被另一个section引用会产生问题，最终在binutils-2.17/gas/expr.c 1877行出错。而 gcc-3.3.6中的libgcc2.c恰巧会产生一个section中的符号被另一个section引用的MIPS代码。而binutils-2.15能根其一起编译的原因很简单，DIFF_EXPR_OK以及相关的代码都在。

具体解决方式为：
binutils-2.17 /gas/config/tc-mips.h
在165行加入
#define UNDEFINED_DIFFERENCE_OK
binutils-2.17/gas/expr.c
1873行
#ifdef DIFF_EXPR_OK
换为
#if ((defined DIFF_EXPR_OK) || (defined TC_MIPS))
这样再编译就可以让gcc-3.3.6正常编译了。

当然具体有啥后果我就不好说了，呵呵。

binutils-2.17竟然能跟gcc-3.4.6一起用

前几天还提过binutils 2.17跟gcc-3.3.6不能一起编译的问题，俺明明记得俺后来用gcc-3.4.6也测试过有同样的问题，然后就换成了binutils-2.15没再弄。
今天俺突然来了兴致，决定解决一下这个问题顺便发到maillist上。找到了出问题的原因(发完这个日志一会单独写个日志介绍)， 胡乱改了一下发现binutils-2.17能和gcc-3.3.6一起编译了，于是准备发帖子到MAILLIST。为了表示测试的充分，俺特地弄出gcc-3.4.6一起编译看看，竟然发现我没改过的binutils也能跟gcc-3.4.6一起编译，早知道这样我折腾啥呢？晕！

GAS可以输出JAVA CLASS了(JNL)

其实昨天就可以输出了，不过在加了一个\n之后有点小BUG，今天修正了这个BUG，现在都正常了。前几天在SF申请了项目，回头项目通过就发布在哪里。
JNL今年的计划基本是作完了，恭喜自己一下。:)

BINUTILS 2.17带来的麻烦

想完整的编一套MIPS的东西放在QEMU上玩玩，先编译的BINUTILS 2.17，没问题，在编译GCC报错：
/home/zh/qemu/gccbuild/gcc/xgcc -B/home/zh/qemu/gccbuild/gcc/ -B/home/zh/mipseb-linux/bin/ -B/home/zh/mipseb-linux/lib/ -isystem /home/zh/mipseb-linux/include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc- 3.3.6/gcc -I../../gcc-3.3.6/gcc/. -I../../gcc-3.3.6/gcc/config -I../../gcc-3.3.6/gcc/../include  -DL_divdi3 -c ../../gcc-3.3.6/gcc/libgcc2.c -fexceptions -fnon-call-exceptions -o libgcc/./_divdi3.o
/tmp/ccqez6rl.s: Assembler messages:
/tmp/ccqez6rl.s:956: Error: operation combines symbols in different segments
make[2]: *** [libgcc/./_divdi3.o] Error 1
弄了一个2.15发现没有问题，网上一搜发现这个问题已经在04年有人提出了解决的PATCH， http://sources.redhat.com/ml/binutils/2004-05/msg00112.html
但是从CVS弄下来的当前版本这个问题还是没有得到解决，搜了一下MAILLIST发现也有几个人问同样的问题。不知道maintainer在TNND干什么呢。
只是一个符号相关的小问题，我懒得弄了，换2.15了事。

SKYEYE基本可以稳定和GDB一起编译了(SKYEYE)

增加了一个TATGET_OPS，编译什么的也都跟GDB整合在一起了，而且在configure里设置是否包含SKYEYE，不过如果选择SKYEYE就会自动去掉GDB的SIM，因为SKYEYE里太多函数跟SIM里面的函数名字一样了，原因自不必说了。
用时有点长了，其实1到2天就应该能搞定的工作，不过毕竟是假期，人总是不容易集中精力的，呵呵！话说回来，其实我好像任何时候都不太容易集中精力的样子。
对了！我换SUSE为UBUNTU耽误的2天。
下面要作的工作就是就是把各种调试功能加到TATGET_OPS里了，希望一切顺利。

BTW：作了以后还是那个感觉：SKYEYE的代码结构实在太乱了，当时真不该这么着急从GDB中分出来，令人不爽。

BFD读的两个没做的事情(JNL)

field没有读入section，同时每个section初始化的时候没将descriptor加入到used_by_bfd上。

opcodes中有几条指令没做(JNL)

有几条指令的反汇编函数没有做，具体在jvm-opc.c标记//tea的地方。

计划在GAS功能做稳定后再做。

BFD读入CLASS基本检查做完(JNL)

主要完成的是指向constant_pool是否是需要的TAG类型，这样后面可以直接根据需要进行任意的使用，不用再考虑是否会导致类型不对长度不对代码出错。
attribute是否符合其出现要求的部分没有进行检查，现在认为还不需要进行这种类型的检查。
其中包含的PC值也没有做检查。

BFD需要做的事情(JNL GNU)

1.CLASS读入后针对每个field interface method attribute中间指向的constant_pool没有进行检查。
2.初始化section的时候 field没有加入。
3.初始化section的时候 将symbol也同时在其中初始化。这个优先级比较高，先做了。
4.interface怎么办？现在没考虑。
5.section上LINE信息的问题 。