core文件怎么分析_方舟编译器学习笔记7 对java2jar及方舟工具链的进一步分析

在前文 源码编译 中一文中我们介绍了关于源码的编译，随后在 可执行文件简介 对方舟工具链的几个工具的执行情况进行了简单的验证。但是，我只是在out/bin的目录下直接进行验证，并未结合samples目录的测试用例进行验证。最近看到有不少大佬对测试用例进行编译，有所启发，我分析了测试用例的Makefile和java2jar的内容，有一点新的收获，在此做简要的分享。

java2jar其实本身是一个很简单的小脚本工具，要做的就是将Java文件编译成class文件之后，然后进行打包。但是根据 可执行文件简介 的内容，其运行存在一定的问题，虽然做了一些修改，但是还存在一些问题。我们先看java2jar的源码：

#!/bin/bash
OUTPUT=$1
CORE_ALL_JAR=$2
shift 2
javac -g -d . -bootclasspath ${CORE_ALL_JAR} $@
jar -cvf ${OUTPUT} *.class                                                                         

其中涉及到两个输入，$1和$2。$1是要输出的jar包，$2是要输入一个叫CORE_ALL_JAR。之前我也尝试了各种对于java2jar的输入，不得其要领，看到大佬们构建测试用例，才想到从测试用例的Makefile借鉴方舟的工具链使用。所以查看samples/helloworld/Makefile：

APP = HelloWorld
include $(MAPLE_BUILD_CORE)/maple_test.mk

而进一步查看build/core/maple_test.mk：

include $(MAPLE_BUILD_CORE)/maple_variables.mk

test: $(APP_S)
include $(MAPLE_BUILD_CORE)/mplcomb.mk
include $(MAPLE_BUILD_CORE)/jbc2mpl.mk
include $(MAPLE_BUILD_CORE)/java2jar.mk

.PHONY: clean
clean:
	@rm -rf *.jar
	@rm -f *.class
	@rm -f *.mpl
	@rm -f *.mplt
	@rm -f *.s
	@rm -f *.groots.txt
	@rm -f *.primordials.txt
	@rm -rf comb.log

这里面又包含了mpcomb.mk、jbc2mpl.mk、java2jar.mk这三个文件。我们先查看java2jar.mk，因为前文也分析过，它是工具链的第一个环节，具体源码为：

$(APP_JAR): %.jar : %.java
	$(JAVA2JAR) $(APP_JAR) ${MAPLE_ROOT}/libjava-core/java-core.jar "$(wildcard *.java)"

我们看到，这里在输入java文件之前，输入了一个java-core.jar包，这个包就是前面java2jar中的CORE_ALL_JAR。这个包在这次发布的时候并没有提供，这也是不少同仁都验证发现的问题。这个才是导致之前关于java2jar总不能达到预期的结果。

那么我们继续看看jbc2mpl.mk，以查看jbc2mpl是怎么具体使用的，其具体源码为：

$(APP_MPL): %.mpl : %.jar $(JBC2MPL_BIN)
	$(JBC2MPL_BIN) --mplt $(LIB_MPLT) -injar $(APP_JAR) -out $(APP)

这里也要求输入一个LIB_MPLT文件，也就是一个mplt的格式的库。发布中没有发现相关的mplt库，所以这个库的缺失是我们之前jbc2mpl总是失败的原因。所以，从我们目前能看到，缺失了一个java-core.jar以及一个mplt库（方舟的中间格式之一），导致第一步骤和第二步骤都无法运行。所以，也没办法继续运行后两个可执行文件maple和mplcg。

而maple和mplcg的两个可执行文件的运行方式，也可以从Makefile中看到一些信息。mplcomb.mk:

$(APP_S): %.VtableImpl.s : %.mpl $(MAPLE_BIN) $(MPLCG_BIN)
	$(MAPLE_BIN) --infile $< $(MPLCOMBO_FLAGS) --save-temps

maple_variables.mk

TARGETS := $(APP)
LIB_MPLT := $(MAPLE_ROOT)/libjava-core/libjava-core.mplt
APP_CLASS := $(foreach APP, $(TARGETS), $(APP).class)
APP_JAR := $(foreach APP, $(TARGETS), $(APP).jar)
APP_MPL := $(foreach APP, $(TARGETS), $(APP).mpl)
APP_MPLT:=$(foreach APP, $(TARGETS), $(APP).mplt)
APP_VTABLEIMPL_MPL := $(foreach APP, $(TARGETS), $(APP).VtableImpl.mpl)
APP_S := $(foreach APP, $(TARGETS), $(APP).VtableImpl.s)

JAVA2JAR := $(MAPLE_ROOT)/out/bin/java2jar
JBC2MPL_BIN := $(MAPLE_ROOT)/out/bin/jbc2mpl
MAPLE_BIN := $(MAPLE_ROOT)/out/bin/maple
MPLCG_BIN := $(MAPLE_ROOT)/out/bin/mplcg
MPLME_FLAGS := --quiet
MPL2MPL_FLAGS := --quiet --regnativefunc --maplelinker
MPLCG_SO_FLAGS := --fpic
MPLCG_FLAGS := --quiet --no-pie --verbose-asm --maplelinker
MPLCOMBO_FLAGS := --run=me:mpl2mpl:mplcg --option="$(MPLME_FLAGS):$(MPL2MPL_FLAGS):$(MPLCG_FLAGS) $(MPLCG_SO_FLAGS)"

从这个里面，我们可以看到maple和mplcg两个可执行文件，是放到一个阶段执行的。我们总结起来，可以分为三个阶段：1、java2jar；2、jbc2mpl;3、maple和mplcg。

前两个阶段第一个阶段需要一个额外的java-core.jar包，第二个阶段需要一个额外的mplt格式的库。综合分析起来，有点诡异，其实从测试用例的角度来看，我们就缺少一个运行时的库。所以，java-core.jar包可能就是这个库。在这种推论下，那么java2jar添加这个库之后，我们后续的信息应该已经完整了。那么在第二个阶段还缺一个mplt的库，这有点奇怪，这时候这个库还缺什么？而且java2jar，不管从名字还是从程序的内容来讲，都是一个将java文件变成一个jar包的过程，不应该再依赖其他的jar包。倒是第二个阶段在生成IR的时候，添加运行时的mplt的库，才符合逻辑。在这种情况下，我将java2jar的源码做了更改：

#!/bin/bash
OUTPUT=$1
JAVA_FILE=$2
shift 2
javac -g -d . ${JAVA_FILE}
jar -cvf ${OUTPUT} *.class   

这样，java2jar可执行文件就可以通过java2jar out.jar test.java这种格式，来输出一个包含test.class的out.jar包。这样，java2jar可执行文件就可以和我们预期一样正确的执行了。

这种时候，我们的第一个工具java2jar已经可以正常执行了，一旦有了运行时的库（java-core.jar），我们或许可以尝试将其变成mplt格式，或者直接交给jbc2mpl，结合输入的java文件，直接得到一个最终的IR。因为，jbc2mpl的运行模式我们在前文已经介绍过了，是可以直接接受jar格式的输入，或者是mplt格式的输入的。当然，这种是一个猜测。因为从一个编译器的设计来讲，打包就是打包，只有在生成IR的时候,或许才会给相关的缺失的部分补充信息，所以即使是有运行时库，也应该是在这个阶段补充。所以，我是觉得，真是能找到缺失的java-core.jar的话，可能只需要在jbc2mpl补充就可以了，java2jar就是个打包程序，根本不需要额外的库。

目前的这些理解和猜测，还有待进一步验证，我会继续深入了解这些工具，争取早日搞清楚这几个工具的正常运行。