Shulou(Shulou.com)06/01 Report--

Editor to share with you how to modify, compile, GDB debug openjdk8 source code under the docker environment. I hope you will get something after reading this article. Let's discuss it together.

Let's compile openjdk first: first, download the files needed to build the image by commanding git clone git@github.com:zq2599/centos7_build_openjdk8.git, then open the console to enter the centos7_build_openjdk8 directory, and execute

Docker build-t bolingcavalryopenjdk:0.0.1.

This builds the image file, and then executes the command to start the docker container (the parameter "- security-opt seccomp=unconfined" in the command has a special use, which I'll talk about later):

Docker run-name=jdk001-security-opt seccomp=unconfined-idt bolingcavalryopenjdk:0.0.1

Then execute the following command to enter the console of the container:

Docker exec-it jdk001 / bin/bash

After entering the console of the container, execute the following two commands to start compilation:

. / configure-- with-debug-level=slowdebugmake all ZIP_DEBUGINFO_FILES=0 DISABLE_HOTSPOT_OS_VERSION_CHECK=OK CONF=linux-x86_64-normal-server-slowdebug

These are the steps for compiling openjdk, please start compiling, because we will use it later, we will use the compiled jdk for debugging.

Now let's look at the source code. The goal of this analysis is to focus on the familiar java-version command. What exactly did jvm do when we typed this command on the terminal?

The whole process of analysis and verification is as follows:

Preparation: it is very inconvenient to see the source code through vim in the container, so I copied a copy of the openjdk source code on my computer (download address: http://www.java.net/download/openjdk/jdk8/promoted/b132/openjdk-8-src-b132-03_mar_2014.zip), opened the openjdk source code with sublime text3, and then went to the docker container to modify it through vi when it really came time to modify.

Find the program entry

The first step is to match the entry of the program with the source code. First, find the entry main function. The steps are as follows:

In the / usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/bin directory within the docker container, execute the following command to enter the command line mode of GDB:

Gdb-- args. / java-version

As shown in the following figure, you can see that you have entered GDB command line mode, and you can continue to enter GDB commands:

Enter the b main command, and at the breakpoint of the main function, GDB will return the information about the location of the breakpoint. As shown in the figure below, the location of the main function is / usr/local/openjdk/jdk/src/share/bin/main.c, line 97:

Then enter the l command to print the source code, as shown below:

On the computer outside the container, open main.c through sublime text3 or other ide, as shown below, and start reading the code:

Read the code sequentially

There is not much code in the main function, but there are several macro definitions that disturb our thinking. Literally, macros such as # ifdef _ WIN32 should only take effect on the windows platform, but we can't infer literally every time. Stepping through the breakpoint is the most direct way, but before we break the point, let's solve a problem left over, which is very important:

Remember our command to start the docker container:

Docker run-name=jdk001-security-opt seccomp=unconfined-idt bolingcavalryopenjdk:0.0.1

What is the use of the-security-opt seccomp=unconfined argument in the command? Why mention this parameter again before the break point?

This parameter is related to the security mechanism of Docker. Here is a link to the specific document. Readers are asked to understand it for themselves. To put it simply, Docker has a Seccomp filtering function, which allows users to customize "allow", "deny", "trap", "kill" and or "trace" operations on system calls (syscall) in the container in the way of Berkeley packet filter (Berkeley Packet Filter, abbreviation BPF). Due to the limitation of Seccomp filtering, under the default configuration, run will fail when we use GDB, so add the parameter-security-opt seccomp=unconfined when executing docker run to disable the function of seccomp profile.

I didn't know the limitation of seccomp profile before. I started the container with the command docker run-name=jdk001-idt bolingcavalryopenjdk:0.0.1. The compilation was successful, but there was a problem when debugging with GDB, as shown in the following figure:

In the image above, the commands "enter GDB" and "b main" (add breakpoints) in the yellow box can be executed normally, but the "r" (running program) command in the red box prompts the error "Error disabling address space randomization: Operation not permitted" when executing the "n" (single-step execution) command.

The remaining problems have been clarified, and you can continue to track the code. We have typed "b mian" in GDB before, and made a breakpoint for the main function. Now enter "r" to start execution, and then you will see that the breakpoint of the main function has taken effect. Enter "n" to track which line the code has been executed to, as shown below:

The original code execution location is 97122123125, which corresponds exactly to the source code of the following figure:

With the GDB artifact, you can happily read the source code:

In the main function of main.c, call the JLI_Launch function. In Sublime text3, place the mouse in the "JLI_Launch" position, and a small window pops up, showing the declaration and definition of the JLI_Launch function with two links, as shown below:

Click the first link and jump to the defined location of the JLI_Launch function:

/ / initialize the debug flag bit according to the environment variable, whether subsequent logs will be printed by this debug flag to control InitLauncher (javaw); / / if debug is set, some auxiliary information DumpState (); if (JLI_IsTraceLauncher ()) {int i; printf ("Command line args:\ n"); for (I = 0; I) will be printed.

< argc ; i++) { printf("argv[%d] = %s\n", i, argv[i]); } AddOption("-Dsun.java.launcher.diag=true", NULL); } //如果设置debug标志位，就打印命令行参数，并加入额外参数 //选择jre版本，在jar包的manifest文件或者命令行中都可以对jre版本进行设置 SelectVersion(argc, argv, &main_class); /* 设置一些参数，例如jvmpath的值被设置成jdk所在目录下的"lib/amd64/server/l"子目录，再加上宏定义JVM_DLL的值"libjvm.so"，即：/usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/lib/amd64/server/libjvm.so */ CreateExecutionEnvironment(&argc, &argv, jrepath, sizeof(jrepath), jvmpath, sizeof(jvmpath), jvmcfg, sizeof(jvmcfg)); //记录加载libjvm.so的起始时间，在加载结束后可以得到并打印出加载libjvm.so的耗时 ifn.CreateJavaVM = 0; ifn.GetDefaultJavaVMInitArgs = 0; if (JLI_IsTraceLauncher()) { start = CounterGet(); } //加载/usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/lib/amd64/server/libjvm.so if (!LoadJavaVM(jvmpath, &ifn)) { return(6); } if (JLI_IsTraceLauncher()) { end = CounterGet(); } JLI_TraceLauncher("%ld micro seconds to LoadJavaVM\n", (long)(jint)Counter2Micros(end-start)); ++argv; --argc; if (IsJavaArgs()) { /* Preprocess wrapper arguments */ TranslateApplicationArgs(jargc, jargv, &argc, &argv); if (!AddApplicationOptions(appclassc, appclassv)) { return(1); } } else { //classpath处理 /* Set default CLASSPATH */ cpath = getenv("CLASSPATH"); if (cpath == NULL) { cpath = "."; } SetClassPath(cpath); } //解析命令行的参数 if (!ParseArguments(&argc, &argv, &mode, &what, &ret, jrepath)) { return(ret); } 到这里先不要继续往下读，我们进ParseArguments函数中去看看： 如上图红框所示，解析到"-version"参数的时候，会将printVersion变量设置为JNI_TRUE并立即返回。 继续阅读JLI_Launch函数： //如果有-jar参数，就会根据参数设置classpath if (mode == LM_JAR) { SetClassPath(what); } //添加一个用于HotSpot虚拟机的参数"-Dsun.java.command" SetJavaCommandLineProp(what, argc, argv); /* Set the -Dsun.java.launcher pseudo property */ //添加一个参数-Dsun.java.launcher=SUN_STANDARD，这样JVM就知道是他的创建者的身份 SetJavaLauncherProp(); //获取当前进程ID，放入参数-Dsun.java.launcher.pid中，这样JVM就知道是他的创建者的进程ID SetJavaLauncherPlatformProps(); return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret); 接下来在JVMInit函数中，ContinueInNewThread函数中会调用ContinueInNewThread0函数，并且把JavaMain函数做为入参传递给ContinueInNewThread0，ContinueInNewThread0的代码如下： //如果指定了线程栈的大小，就在此设置到线程属性变量attr中 if (stack_size >

0) {pthread_attr_setstacksize (& attr, stack_size);} / / create a thread. The external JavaMain is also passed to the child thread. After the child thread is created, it will first execute JavaMain (that is, the continuation parameter) if (pthread_create (& tid, & attr, (void* (*) (void*)) continuation, (void*) args) = = 0) {void* tmp After the child thread is created successfully, the current thread waits here to block until the child thread ends pthread_join (tid, & tmp); rslt = (int) tmp;} else {/ * * Continue execution in current thread if for some reason (e.g. Out of * memory/LWP) a new thread can't be created. This will likely fail * later in continuation as JNI_CreateJavaVM needs to create quite a * few new threads, anyway, just give it a try.. * / / if the creation of a child thread fails, execute the JavaMain function rslt = continuation (args) passed outside the current thread directly;} / / destroy the pthread_attr_destroy (& attr) without using the thread attribute

While reading the source code of the ContinueInNewThread0 function, I came across the comments in the red box below, which is the best comment I have ever seen (personal opinion only). When I saw pthread_create being called, I thought, "what happens if you fail to create a thread?" Then this comment appears, telling me that "if the creation thread fails for some reason (such as a memory overflow), the current thread will continue to execute JavaMain, but errors may still occur in subsequent operations, such as the JNI_CreateJavaVM function will create some new threads, so executing JavaMain on the current thread is just an attempt."

It benefits a lot to clarify the problem in the right place and make appropriate hints for follow-up development. Good code with good comments is really beneficial.

Following the above analysis, the JavaMain function is called in the new thread, which is as follows:

/ / under windows and linux, RegisterThread is an empty function, and mac implements RegisterThread (); / / record the current time and count the time spent initializing JVM using start = CounterGet (); / / call the CreateJavaVM method in the libjvm.so library to initialize the virtual machine if (! InitializeJVM (& vm, & env, & ifn)) {JLI_ReportErrorMessage (JVM_ERROR1); exit (1) } / / call the static method (sun.launcher.LauncherHelper.showSettings) of the java class, and print the setting information of jvm if (showSettings! = NULL) {ShowSettings (env, showSettings); CHECK_EXCEPTION_LEAVE (1) } / * call the static method (sun.misc.Version.print) of the java class, print: 1.java version information 2.java runtime version information 3.java virtual machine version information * / if (printVersion | | showVersion) {PrintJavaVersion (env, showVersion); CHECK_EXCEPTION_LEAVE (0); if (printVersion) {LEAVE ();}}

At this point, you don't have to read the following code, because the printVersion variable is true, so after the PrintJavaVersion is executed, the LEAVE () function is called to separate the virtual machine from the current thread, and then the thread ends and the process ends.

At this point, we should focus on the PrintJavaVersion function to see how the content that normally executes "java-version" is generated.

When you go to the PrintJavaVersion function, you don't have much content, but you can learn how jvm in the c language executes static methods in the java class, as follows:

Static voidPrintJavaVersion (JNIEnv * env, jboolean extraLF) {jclass ver; jmethodID print; / / find sun.misc.Version NULL_CHECK from bootStrapClassLoader (ver = FindBootStrapClass (env, "sun/misc/Version")) / * since there is no-showVersion argument in the command line argument, extraLF is not equal to JNI_TRUE, so the sun.misc.Version.print method is called here, if the command is "java-showVersion" So the pringlin method is called * / NULL_CHECK (print = (* env)-> GetStaticMethodID (env, ver, (extraLF = = JNI_TRUE)? "println": "print", "() V"); (* env)-> CallStaticVoidMethod (env, ver, print);}

At this point, the work of reading the source code seems to be coming to an end, but it is not that simple. Readers, please search the Version.java file under the openjdk folder. Although you can find several Version.java, there is only one file whose package path matches sun/misc/Version.java. The upper directory of this Version.java is the test directory, not the src directory, which is obviously just the test code, not the Version class called in the above PrintJavaVersion function:

Now the question is, where is the real Version class?

When we searched the Version.java file just now, we searched the folder where the openjdk source code was downloaded. Now let's go back to the / usr/local/openjdk directory in the docker container and enter find. /-name Version.java to try. The result is shown below. In the build directory, four sun/misc/Version.java files are found:

In the above figure, there are four sun/misc/Version.java files, and the paths of the last three Version.java files contain paths such as get_profile_1,get_profile_2. Here, it is guessed that it will only be generated under the premise of certain scenarios or settings. (I am sorry to readers, this is my guess, the specific reason is not clear yet, if you know, please tell some, thank you) So let's focus on the first file here:

/ usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/gensrc/sun/misc/Version.java

The Version.java file is not in the downloaded source code, but it is in the build directory after compilation, and the file path contains the gensrc directory, which is obviously generated during the compilation process. OK, let's look for the answer from Makefile: in the Makefile file, Main.gmk will be called, as shown below:

BuildJdk.gmk is called in Main.gmk, as shown below:

GenerateSources.gmk is called in BuildJdk.gmk, as shown below:

GensrcMisc.gmk is called in GenerateSources.gmk, as shown below:

After opening the GensrcMisc.gmk file, everything is clear at a glance. As shown in the code in the following figure, the / src/share/classes/sun/misc/Version.java.template file is used as a template to replace some placeholders in the Version.java.template file with existing variables through the sed command, and the file after replacing the placeholder is Version.java

We can see that a total of five placeholders were replaced:

@ @ launcher_name@@ replace $(LAUNCHER_NAME) @ @ java_version@@ with $(RELEASE) @ @ java_runtime_version@@ replace with $(FULL_VERSION) @ @ java_runtime_name@@ replace with $(RUNTIME_NAME) @ @ java_profile_name@@ replace with $(call profile_version_name, $@)

Let's take a look at what's in Version.java.template:

Sure enough, there are five placeholders, and then there is a static method public static void init (), which sets the contents of the placeholders to the global properties.

It is finally clear that the original Version.java is derived from the Version.java.template file and is generated when it is compiled and built, and the placeholders in the Version.java.template file are replaced with the corresponding variables.

Now, in the docker container, execute the command vi / usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/gensrc/sun/misc, and open Version.java to have a look, as shown below:

Sure enough, it has all been replaced, together with the init method in the static code block, which means that when the class is loaded, the application has these three global attributes: java.version,java.runtime.version,java.runtime.name

After figuring out the context of Version.java, there is one small problem left to figure out. In the GensrcMisc.gmk file, where do the variables that replace placeholders come from when you replace placeholders in Version.java.template files with the sed command? Or where does the sum of "1.8.0-internal-debug", "OpenJDK Runtime Environment" and "1.8.0-internal-debug-_2017_04_21_04_39-b00" in the expressions java_version = "1.8.0-internal-debug", java_runtime_name = "OpenJDK Runtime Environment", java_runtime_version = "1.8.0-internal-debug-_2017_04_21_04_39-b00" in the Version.java file come from? At this time, the easiest way is to use "RELEASE", "FULL_VERSION" and "RUNTIME_NAME" to do a global search, which can be found soon. Let me sort it out:

The following actions are performed in calling autogen.sh autogen.sh in calling common/autoconf/configure common/autoconf/configure in the openjdk/configure file:

Replace the contents of configure.ac and output them to generated-configure.sh, where autoconfig is used for configuration

The definition of these variables JDK_VERSION,RUNTIME_NAME is clearly written in calling spec.gmk.in spec.gmk.in in calling basics.m4 basics.m4 in configure.ac, as shown below:

PRODUCT_NAME and PRODUCT_SUFFIX are the configuration items for autoconfig, which are defined in the openjdk/common/autoconf/version-numbers file, which is a configuration file for autoconfig, as shown below:

After sorting out the source of the variables, let's take a look at the code. The print method of the sun.misc.Version class, such as the following figure, is as simple and clear as ever, taking out some global properties and printing them out:

At this point, the source code corresponding to the java-version command has been analyzed. To sum up, in the entry main function, some variables are printed out by calling the print static method of the Version class of java. These variables are output to the automatically generated java source code through autoconfig.

Now that you have read the source code, it's time to practice it yourself. Here we make two changes, remember to use the vi tool in the docker container to change:

Modify the Version.java.template file to let java-version output one more line of code during execution, as shown below in the red box:

Modify / usr/local/openjdk/common/autoconf/version-numbers, and modify the value of PRODUCT_SUFFIX. According to the previous understanding, after PRODUCT_SUFFIX is modified, the output runtime name will change, as follows:

After the changes are completed, go back to the / usr/local/openjdk directory and execute the following two lines of command to start the compilation:

. / configure-- with-debug-level=slowdebugmake all ZIP_DEBUGINFO_FILES=0 DISABLE_HOTSPOT_OS_VERSION_CHECK=OK CONF=linux-x86_64-normal-server-slowdebug

After compilation, go to the / usr/local/openjdk/build/linux-x86_64-normal-server-slowdebug/jdk/bin directory to execute. / java-version, and the output is shown in the figure below. You can see that our changes have taken effect.

After reading this article, I believe you have a certain understanding of "how to modify, compile, GDB debug openjdk8 source code in docker environment". If you want to know more about it, welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.