ubuntu下编译openjdk成为可调试版

zjt5916 2011-05-20

具体编译ubuntu需要安装哪些依赖软件 RednaxelaFX大大的一边博客中已经写过了
我刚开始在编译的时候生成的openjdk不是debug版的所以编译完成后发现用gdb没法调试后来我在顶层目录里边的makefile发现一边有这样一段注释 taget_help :
all
help
check
sanity
debug_build
clean
.....
就是在make的时候可以加的参数其中debug_build它给的解释就是生成debug版的openjdk 所以我就又在重新编译它（都怪我以前没有写过makefile ，只能从头学起）
目前我的openjdk7还在编译的过程中等它在编译出来后我看看它可不可以用gdb调试

还有一件事就是我编译openjdk是想做这样一件事弄清楚它从.class 到jvm 然后 jvm到本地函数调用这个过程是什么样然后等我弄清楚了我就想是不是我自己可以写一些本地的c库然后在写一些核心的java类扩展jdk的新功能(比如说加个蓝牙呀 wifi功能之类的) 这只是小的一些想法在实践的过程中肯定会遇到各种问题
希望各位大大能给小的提些建议这个调试的过程中应该注意些什么

RednaxelaFX 2011-05-21

如果目的只是“能够写JNI程序”的话那完全不需要先费力看JVM是怎么实现的，只要看JNI规范在看几个例子就好了。蓝牙、Wi-Fi这些外围设备的功能直接在库一级做就好了，完全不需要侵入到VM内。

如果你用默认配置来build出OpenJDK，在生成的build结果目录里应该有j2sdk-image目录，这个是product build的JDK，另外还应该有j2sdk-debug-image目录，里面就是fastdebug build。用后者调试起来会容易那么一点点。

要用gdb调试有动态链接库的程序的话，最好是先用gdb启动这个程序完整的跑一次。这样gdb就会记住被加载过的动态链接库的符号信息，下次在用gdb启动就能在动态链接库里的代码很方便的下断点了。

但实际上要调试HotSpot最麻烦的就是里面动态生成的代码。例如说默认用的解释器（template interpreter）就是在VM启动过程中生成出来的。再例如说从C调用Java方法也会经过动态生成的stub。更不用说被动态编译的Java方法了。这些代码无论在哪个build里调试起来都不容易，特别是因为它们缺乏gdb能识别的符号信息。

有几种办法能应对这问题。一个是改善HotSpot的实现，让它生成gdb能识别的符号信息。这点可以向V8学习。
但如果不修改HotSpot的代码，就在现在的实现上要调试动态生成的代码也可以。只要你对代码足够的熟悉…这个时候你就得靠stepi之类的方式做汇编级调试，但也不会真的很难，就是麻烦而已。

zjt5916 2011-05-21

RednaxelaFX 写道

奥我明白唠可以用jni 然后自己封装出来几个神马WifiHelper类就可以了
这样就可以做到扩展的目的
那我们调试hotspot的目的在什么地方呢调试它有什么作用呢 ?

RednaxelaFX 2011-05-21

zjt5916 写道

这就要看你的目的了…
要了解内部实现方式，调试是一种有效的手段。如果在VM内出bug了的话调试也是解决问题的重要手段。再要说的话…这是兴趣驱动的

zjt5916 2011-05-21

RednaxelaFX 写道

zjt5916 写道

那如果想把jdk中比如awt这些包砍掉把它定制成我自己的jdk
这个该从那部分着手呢。

RednaxelaFX 2011-05-21

zjt5916 写道

那如果想把jdk中比如awt这些包砍掉把它定制成我自己的jdk
这个该从那部分着手呢。

只是要砍掉awt的话那在make的时候传个headless参数就好了。具体那个参数的拼写是什么我记不住了，抱歉。现在不在电脑上没办法帮你查。

如果是别的部分的话…感觉你关注的都是类库的裁剪，从jdk目录入手就好了。主要关注的是classes目录里面是Java代码，以及native目录里面是C写的JNI代码

zjt5916 2011-05-22

RednaxelaFX 写道

zjt5916 写道

那如果想把jdk中比如awt这些包砍掉把它定制成我自己的jdk
这个该从那部分着手呢。