It takes a long time to Yi the whole openjdk, and there are a lot of things that are not needed. In the case of a hotspot, it's just a matter of the code on the Hotspot section.
Below is a simple record under Yi debugging hotspot some steps.
I. Compilation of Yi
Enter Hotsopt's Make directory:
1 |
cd code /cpp/openjdk/hotspot/make/ |
You can see a lot of useful information with make help. Of course, look at the makefile file, which also has a lot of useful comments.
Make help outputs the settings of some of the current environment variables, and if not, the natural Yi does not pass.
Set Environment variables:
12345 |
unset java_home export arch_data_ model=64 export jdk_import_path= Code class= "Shell plain" >/usr/lib/jvm/java-7-oracle export alt_bootdir= /usr/lib/jvm/java-7-oracle export zip_debuginfo_files=0 // This doesn't seem to work. The definitions of these variables seem to be in def. make file. There is one such parameter: Full_debug_symbols |
Use make All_beug to make Yi.
After compiling Yi Good, to the directory under OPENJDK/HOTSPOT/BUILD/LINUX/LINUX_AMD64_COMPILER2/JVMG, execute unzip Libjvm.diz, decompression to get debug information file .
This is a pit. By default, the debug information file is compressed, so when debugging with GDB, the following prompt appears:
1 |
no debugging symbols found |
From the output information of the compiled Yi, there is a zip_debuginfo_files parameter, but the environment variable is not effective.
Second, commissioning
In the OPENJDK/HOTSPOT/BUILD/LINUX/LINUX_AMD64_COMPILER2/JVMG directory, there is a hotspot script that, as long as you execute the script, you can start the Java process.
The./hotspot-gdb will automatically enter GDB debugging and stop at the main function entrance.
You can add some JVM startup parameters and so on later.
How does this./hotsopt script work?
Using Sh-x./hotspot to view the execution of the script, you can see that the LD_LIBRARY_PATH environment variable is actually set, and then a./gamma program is called.
12345678910 |
+ LD_LIBRARY_PATH=/home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg:/usr/lib/jvm/java-7-oracle/jre/lib/amd64
+ export LD_LIBRARY_PATH
+ JPARMS=
+ LAUNCHER=/home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg/gamma
+ [ ! -x /home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg/gamma ]
+ GDBSRCDIR=/home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg
+ cd /home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg/../../..
+ pwd
+ BASEDIR=/home/hengyunabc/code/cpp/openjdk/hotspot/build
+ LD_PRELOAD= exec /home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg/gamma
|
in fact, by setting the LD_LIBRARY_PATH environment variable, the priority is to load the Yi good libjvm.so. the code for the hotsopt JVM is Yi linked in the libjvm.so file.
Look at the function init_gdb in the./hotspot and know how it started and set up GDB:
12345678910111213141516171819 |
init_gdb() {
# Create a gdb script in case we should run inside gdb
GDBSCR=
/tmp/hsl
.$$
rm -f $GDBSCR
cat >>$GDBSCR <<EOF
cd `
pwd
`
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
set args $JPARMS
file $LAUNCHER
directory $GDBSRCDIR
# Get us to a point where we can set breakpoints in libjvm.so
break InitializeJVM
run
# Stop in InitializeJVM
delete 1
# We can now set breakpoints wherever we like
EOF
}
|
So, you can actually start debugging.
12 |
export LD_LIBRARY_PATH= /home/hengyunabc/code/cpp/openjdk/hotspot/build/linux/linux_amd64_compiler2/jvmg : /usr/lib/jvm/java-7-Oracle/jre/lib/amd64 gdb |
Execute file./gamma in GdB, and then you can debug it.
third, use Eclipse to debug
Although GDB is powerful and command-rich, it is inconvenient to look at debugging variables. Especially in hotsopt, many things are stored with pointers, sometimes to jump several layers to see the desired information.
Download the CDT version of Eclipse, the new Visual Cinema 6080 or install the CDT plugin.
Import Eclipse Project:
"File", "Import", "C/C + +", "Existing Code as Makefile Project":
Select Linux GCC First:
Then, you can lead the project to eclipse. There will be a lot of error hints, but it doesn't affect our debugging.
Debug in Eclipse:
First, you set the path of the file to be debugged:
Set Ld_library_path:
Then you can debug it. There is one more important place:
To enter the GDB command at run time, you can find a GBD console in the console view, and in the dropdown on the right, there is a GDB trace console.
Iv. some useful stuff
JVMG1 directory is under the O1 optimization, Fastdebug directory is O3 optimized.
The main entry for the Java process is in the: OPENJDK/HOTSPOT/SRC/SHARE/TOOLS/LAUNCHER/JAVA.C file.
In GDB, use the info sharedlibrary command to see which so files are actually used.
Use the file command to determine whether an executable is 32-bit or 64-bit.
To see if a so file contains debug information, you can use the Readelf-s xxx.so command to see if there is a debug-related segment. This method is not necessarily accurate, because debugging information may be placed in an external file.
Yi debugging the Hotspot JVM and debugging the hotspot in eclipse some steps