X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FMakefileGuide.html;h=c13e06fb1f08217620c37273ff143dbc618156e2;hb=550211711acc12a470a66cf55147796f61e923cd;hp=3c73753be1c5ffa9a4f4fb857eadbf6ad7b8b9e5;hpb=cd7c1cae1cfad5490e263829fda7308655a76cbb;p=oota-llvm.git diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html index 3c73753be1c..c13e06fb1f0 100644 --- a/docs/MakefileGuide.html +++ b/docs/MakefileGuide.html @@ -30,7 +30,8 @@
While this document is rightly part of the LLVM Programmer's Manual, it is treated separately here because of the volume of content and because it is often an @@ -237,7 +238,7 @@ LIBRARYNAME = mylib SHARED_LIBRARY = 1 ARCHIVE_LIBRARY = 1 - DONT_BUILT_RELINKED = 1 + DONT_BUILD_RELINKED = 1
says to build a library named "mylib" with both a shared library (mylib.so) and an archive library (mylib.a) version but @@ -259,7 +260,7 @@ -
+In some situations, it is desireable to build a single bytecode module from a variety of sources, instead of an archive, shared library, or bytecode @@ -279,6 +280,40 @@
In some situations, you need to create a loadable module. Loadable modules + can be loaded into programs like opt or llc to specify + additional passes to run or targets to support. Loadable modules are also + useful for debugging a pass or providing a pass with another package if that + pass can't be included in LLVM.
+LLVM provides complete support for building such a module. All you need to + do is use the LOADABLE_MODULE variable in your Makefile. For example, to + build a loadable module named MyMod that uses the LLVM libraries + LLVMSupport.a and LLVMSystem.a, you would specify:
++ LIBRARYNAME := MyMod + LOADABLE_MODULE := 1 + LINK_COMPONENTS := support system ++
Use of the LOADABLE_MODULE facility implies several things:
+A loadable module is loaded by LLVM via the facilities of libtool's libltdl + library which is part of lib/System implementation.
+TOOLNAME = mytool USEDLIBS = mylib - LLVMLIBS = LLVMSupport.a LLVMSystem.a + LINK_COMPONENTS = support system
says that we are to build a tool name mytool and that it requires three libraries: mylib, LLVMSupport.a and @@ -317,36 +352,22 @@
Many tools will want to use the JIT features of LLVM. However, getting the - right set of libraries to link with is tedious, platform specific, and error - prone. Additionally, the JIT has special linker switch options that it needs. - Consequently, to make it easier to build tools that use the JIT, you can - use a special value for the LLVMLIBS variable:
+Many tools will want to use the JIT features of LLVM. To do this, you + simply specify that you want an execution 'engine', and the makefiles will + automatically link in the appropriate JIT for the host or an interpreter + if none is available:
TOOLNAME = my_jit_tool USEDLIBS = mylib - LLVMLIBS = JIT + LINK_COMPONENTS = engine-
Using a value of JIT for LLVMLIBS tells the makefile - system to construct a special value for LLVMLIBS that gives the program all - the LLVM libraries needed to run the JIT. Any additional libraries needed can - still be specified with USEDLIBS. To get a full understanding of how - this changes the linker command, it is recommended that you:
+Of course, any additional libraries may be listed as other components. To + get a full understanding of how this changes the linker command, it is + recommended that you:
cd examples/Fibonacci make VERBOSE=1-
By default, using LLVMLIBS=JIT will link in enough to support JIT - code generation for the architecture on which the tool is linked. If you need - additional target architectures linked in, you may specify them on the command - line or in your Makefile. For example:
-- ENABLE_X86_JIT=1 - ENABLE_SPARCV9_JIT=1 - ENALBE_PPC_JIT=1 --
will cause the tool to be able to generate code for all three platforms. -
This utility target, only available when $(PROJ_OBJ_ROOT) is not the same as $(PROJ_SRC_ROOT), will completely clean the - $(PROJ_OBJ_ROOT) directoy by removing its content entirely and + $(PROJ_OBJ_ROOT) directory by removing its content entirely and reconfiguring the directory. This returns the $(PROJ_OBJ_ROOT) directory to a completely fresh state. All content in the directory except configured files and top-level makefiles will be lost.
@@ -632,6 +653,11 @@ to the compilers and linkers to ensure that profile data can be collected from the tools built. Use the gprof tool to analyze the output from the profiled tools (gmon.out). +