Open Collections

UBC Undergraduate Research

Extending the LLFI tool to support compilation of project files Chan, Abraham Dec 1, 2014

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
52966-Chan_Abraham_EECE496_2014.pdf [ 479.63kB ]
Metadata
JSON: 52966-1.0103306.json
JSON-LD: 52966-1.0103306-ld.json
RDF/XML (Pretty): 52966-1.0103306-rdf.xml
RDF/JSON: 52966-1.0103306-rdf.json
Turtle: 52966-1.0103306-turtle.txt
N-Triples: 52966-1.0103306-rdf-ntriples.txt
Original Record: 52966-1.0103306-source.json
Full Text
52966-1.0103306-fulltext.txt
Citation
52966-1.0103306.ris

Full Text

Extending the LLFI Tool toSupport Compilation of Project FilesSubmitted in partial fulfillment of therequirements for the undergraduate thesis, EECE 496Name: Abraham ChanSupervisor: Karthik PattabiramanDate Submitted: December 1, 2014AcknowledgementsI would like to thank my research supervisor Professor Karthik Pattabiraman for providingthe initial concept and offering continuous guidance over the course of this project. I wouldalso like to express my gratitude to graduate students, Qining Lu and Nithya Narayana-murthy, for assisting me in the development of the command line and GUI componentsrespectively. This project would not have been accomplished without their correspondingcontributions.AbstractLLFI is a LLVM based fault injection tool that performs hardware fault injections at theintermediate representation (IR) level. To perform a fault-injection, the source files mustfirst be compiled into IR, followed by the generation of executables, and the profiling ofthe faults. The pre-existing tool is designed for single C/C++ source files. With increasedinterest from industry to understand their application’s resilience to faults, the LLFI toolmust be extended to operate on whole projects.Multiple alternate solutions were proposed to implement this extension. The preferredsolution comprises of a script to generate a Makefile that takes into account of user options,and subsequently builds the Makefile. This solution is incorporated into both the commandline and GUI tools.The usability of this design is accessed through the deployment of several industry bench-mark applications. The design is evaluated by its efficiency, responsiveness and integrationto the overall workflow. The key challenge of the analysis is on apprehending an existinguser’s workflow in the tool.iiContentsAcknowledgements iAbstract iiList of Definitions iv1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 System Overview 23 Methodology 33.1 Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.1.1 Proposed Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.1.2 Proposed Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.1.3 Proposed Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.1.4 Preferred Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2.1 Command Line Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2.2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Design Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Analysis of Usability 104.1 Benchmark Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.1 Parboil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.2 SPEC CPUTM 2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Results and Discussion 116 Conclusion 127 Future work 12References 13Appendix A 14Appendix B 18iiiList of DefinitionsClangC front-end for the LLVM CompilerClang++C++ front-end for the LLVM CompilerCMakeCross-platform Make tool that automatically creates native MakefilesInstrumentationThe process of creating LLFI executables from an IR fileIRIntermediate representation form, a low-level instruction set close to assemblyLLFIIntermediate Representation Fault Injector ToolLLVMBack-end compiler package, utilized by LLFIMakeTool to manage the formation of executables and other generated files from source codeMakefileFile that contains information about source files, rules, variables and directives toorganize the compilation and linking processProfilingUser defined selection of injectable faultsUsabilityA qualitative measure of user comfortability in using a software applicationiv1 Introduction1.1 BackgroundLLFI is a fault-injection tool that injects hardware faults at the LLVM IR level [1]. Toperform fault-injections, LLFI must first compile source code files into its intermediate rep-resentation form. LLFI currently supports the compilation of single C/C++ source codefiles. With a growing industry demand to understand applications’ fault tolerance, particu-larly in traditionally unsafe languages, LLFI must be expanded to perform fault-injectionson projects files. Typical projects consist of an assortment of source files, header files andobject files. Presently, a workaround that exists for the compilation of multiple code filesinvolves the manual modification of the Makefile. However, this workaround must be appliedthrough the command line application of LLFI, without any support from the LLFI-GUI.1.2 Purpose and ScopeThis report investigates the extension of the LLFI tool to formally enable compilationof C/C++ project files. The scope of this report will cover alternative proposed solutions,followed by the selection of the preferred solution, and concluded with an evaluation ofusability on the selected solution. Usability of the implemented solution will be assessedusing industry benchmark applications.1.3 ObjectivesThe objective of this project is to introduce the notion of project file compilation ofLLFI. The implemented solution will be applied to both the LLFI command line tool andthe LLFI-GUI application. An integrated command line and GUI application will facilitatethe user’s experience of the tool, as well as, provide consistency over supported features.12 System OverviewThe typical workflow, shown in Figure 1, for a fault-injection on a single source file consistsof the following order of steps:1. Compilation2. Instrumentation3. Profiling4. Fault-injectionFigure 1: High Level Design of Pre-existing SystemThis report focuses on modifying the compilation process to accomodate project files. Thecompilation process involves a LLVM-based compiler, which converts the source files intoLLVM IR format. Clang is a C language front-end for the LLVM compiler [2]. Source filesin C are compiled with Clang while source files in C++ are compiled with Clang++.23 Methodology3.1 Proposed SolutionsThree alternative solutions were proposed for LLFI to enable project file compilation:1. Modification of the CompileToIR script to parse project files2. Creation of a LLFI custom Makefile3. Creation of a LLFI custom CMakeLists.txt fileAll of the solutions above are compatible with both the command line tool and the GUItool. The benefits and drawbacks of each of these proposed solutions are examined below.3.1.1 Proposed Solution 1The first proposed solution is to modify the existing CompileToIR script to permit pars-ing of the project files. The CompileToIR script is implemented as a python executablecommand, which accepts source files, an output filename, and compiler options as input pa-rameters and generates a LLVM IR file. This solution would consist of modifying the inputfor source files to accept a project folder instead. All valid C/C++ source files within theproject folder would be parsed and aggregated into a list. CompileToIR would execute withthis list of source files, along with additional compiler options as indicated by the user. Thisapproach would pose minimal impact to users as the python script internally discerns projectfiles from individual source files. However, there are two main drawbacks to this solution.Firstly, this solution does not facilitate the input of custom compiler flags. As larger andspecialized projects are run with the LLFI tool, users may seek to configure custom compilerflags. Secondly, this solution is not scalable for large projects. This solution would involveparsing and recompiling the project file each time a single code file is modified.3.1.2 Proposed Solution 2The second proposed solution is to create a custom LLFI Makefile. In this solution, aMakeFile is generated with a list of source files and their corresponding list of IR files. Eachsource file is compiled individually with Clang or Clang++ to produce corresponding IRfiles. Afterwards, the IR files are linked together using the LLVM linker to produce a singleIR file. The implementation of this solution consists of a script to generate the Makefile,followed by a Make call to build the Makefile. A custom Makefile would easily enable users toset custom compiler flags and compiler options. Makefiles provide another advantage; theyallow partial compilation of project files such that only the modified files are built each time.Despite these advantages, Makefiles remain platform-dependent, which requires environmentsettings to be set explicitly.33.1.3 Proposed Solution 3The third proposed solution is to create a custom LLFI CMakeLists.txt file. CMake is across-platform Make system that reduces overhead associated with directive and environmentsettings in Makefiles [3]. This solution involves three steps for the compilation process:construction of the CMakeLists.txt, generation of the appropriate Makefile and building theMakefile. The automated construction of the CMakeLists.txt could be implemented as aproject file parsing script, similarly described in Proposed Solution 2. CMake is able todiscern factors such as users’ platforms and source file types to call the applicable compileralong with native settings. CMake offers two main advantages: support for cross-compilationand automatic detection of project compilation flags. However, CMake does not offer aforthright method to input custom compiler flags.3.1.4 Preferred SolutionThe proposed solutions are evaluated with respect to scope, purpose, requirements. Thefirst solution poses a significant drawback in efficiency when encountering large project files.While the third solution offers cross-platform support, LLFI is designed to operate on Linuxsystems. Instead, the most desirable solution is one that best integrates with the existingsystem with the flexibility of accommodating user options. As a result, Solution 2 is thepreferred solution.3.2 Solution DesignThe following section describes the implementation of the preferred solution in both thecommand line tool and the GUI.3.2.1 Command Line ToolPreceding the development of the GUI enhancement for project compilation, a commandline tool was first established to generate the Makefile for an input project file. The Makefilewould be run with “Make” to directly generate the IR file. Figure 2 compares the proposedsystem architecture with the pre-existing system.To implement the selected solution, a new python executable script named ”Gener-ateMakeFile.py” was developed under the $LLFI HOME/llfi/tools directory. The executablepython script is included under Appendix A. The GenerateMakeFile script is based closely onthe original CompileToIR script, with the key difference that the former produces a Makefilefor projects and the latter generates an IR file.As shown in Figure 3, GenerateMakeFile accepts the following parameters as input op-tions: readable, verbose, debug, all, flags, output file name. Examples of use are providedbelow.4Figure 2: New System Design of the Command Line ToolFigure 3: Command Line Options5This command creates a Makefile, which compiles all valid C/C++ source files in thecurrent folder directory into a readable IR file named ”output.ll”.$ GenerateMakeFile −−r eadab le −−a l l −o output . l lThis command creates a Makefile, which compiles the two indicated source files in thecurrent folder directory into a readable IR file named ”output.ll”.$ GenerateMakeFile −−r eadab le −o output . l l source1 . c source2 . cThis command creates a Makefile, which compiles all valid C/C++ source files in thecurrent folder directory into a LLVM bytecode file named ”output.bc”.$ GenerateMakeFile −−debug −−a l l −o output . bcThis command creates a Makefile, which compiles all valid C/C++ source files in thecurrent folder directory into a readable IR file named ”output.ll” along with two additionalcompiler options to generate complete debug information and optimize the build for speed.$ GenerateMakeFile −−debug −−a l l −− f l a g s g Ot −o output . l l3.2.2 GUIThe GUI portion of the solution is designed as a natural extension of the command linetool. With the overarching objective of closer integration between the two interfaces, thecommand line scripts have been designed to allow the GUI to directly execute them. Withthis infrastructure in place, development on the GUI is focused instead on UI design tomaximize the user experience.To preserve users’ workflow on the GUI, the implemented interface extension was designedto minimize user impact. First, the menu tab under “File” was extended to add the optionof “Import Project Folder”. When the option is selected, an open project file dialog, shownin Figure 4, prompts the user to select a project folder. Once a project folder is selected andopened, the GenerateMakeFile script is automatically called to create the Makefile. By de-fault, the Makefile is generated under the selected project folder. This feature is implementedunder the onClickOpenProject() event in the GUI Controller class, presented in Appendix B.6Figure 4: Project File Selection DialogueThe generated Makefile is opened automatically by the LLFI GUI editor. The editorpermits users to make manual adjustments to the Makefile, which is particuarly useful forconfiguring compiler flags. To successfully build the project into IR code, the Makefile mustbe explicitly selected on the left side bar under the current list of files before pressing the“Compile to IR” button. Figure 5 demonstrates the selection of the Makefile. The “Compileto IR” button will call Make to build the project file if the Makefile is selected. Otherwise,it will build the source files separately. This feature is implemented under the onClickCom-pileToIr() event in the GUI Controller class, exhibited in Appendix B.7Figure 5: Makefile Selected Prior to Project CompilationUpon a successful build to IR format, the corresponding IR file will be generated inthe same project folder. This new IR file must be manually imported into the LLFI GUIworkspace. Once the IR file is imported, it must be explicitly selected before the instru-ment button is clicked. Figure 6 illustrates the GUI display upon loading the IR file. Theinstrumentation process produces LLFI executables, which are ready to be profiled for fault-injection.8Figure 6: Instrument on the Selected IR File3.3 Design AssumptionsThere were several design assumptions made in the development of the project compilationfeature.(i) Existing Makefiles are replaced in the project directory.(ii) Project folders have a flat hierarchy of source files.The GenerateMakeFile script creates a Makefile that builds source files into LLVM IR. TheMakefile is generated in the selected project directory, replacing any existing Makefile in theproject. Makefiles do not generally adhere to a standard format, which makes them difficultto parse. Instead, a new custom Makefile is generated by the script.The GenerateMakeFile script assumes that all source files reside directly under the projectfolder. As a result, any source files organized into subdirectories are ignored during thecreation of the Makefile.94 Analysis of UsabilitySoftware usability is defined as a qualitative measure at which users feel comfortablewith the workflow of the application [4]. As this feature is integrated into an existingtool, usability of this application is a paramount factor in evaluating the viability of thedesign. The subsequent factors will be used in assessing usability: efficiency, responsivenessand integration with the existing workflow. Efficiency will be measured through the CPUexecution time of an operation. Responsiveness will be qualitatively evaluated by the abilityof the application to respond to a user request during the execution of a process. Integrationwith the existing workflow will also be evaluated qualitatively.4.1 Benchmark ApplicationsTwo industry benchmarks were used to evaluate the usability of the implemented solu-tion. These benchmarks were Parboil and SPEC CPUTM 2006. While Parboil benchmarkapplications are considerably lightweight, SPEC CPUTM 2006 benchmark applications arespecifically CPU intensive. The analysis below is performed by running the LLFI GUI on a64-bit Ubuntu Linux machine.4.1.1 ParboilThe Parboil benchmark applications are an assortment of computing applications usedto study compilers and computing architecture [5]. They include a range of typical scientificand commercial applications. Each benchmark application comes in several implementationforms: base, Cuda-base, Ocl-base. Base implementations are written for regular computingarchitectures, while Cuda-base and Ocl-base work with specific CPU/GPU architectures.The Parboil benchmark applications are provided by the Impact Research Group at theUniversity of Illinois at Urbana-Champaign. For the purpose of analyzing the performanceof the implemented solution in the LLFI tool, the Parboil benchmark was chosen due to itsrelatively lightweight applications.The ensuing analysis is based on the Sum of Absolute Differences (SAD) benchmarkapplication in its base implementation.Operation Average ExecutionTimeResponsiveness Integration withExisting WorkflowGenerateMakefile 10 seconds Fast Select project folderinstead of individ-ual filesCompileToIR 3 seconds Very fast No changeInstrumentation 20 seconds Moderate No changeProfiling 10 seconds Fast No change10In order to compile the SAD benchmark application, several modifications were madeto the original source files. Particularly, the benchmark source files referenced several localheader files as system header files. These instances were changed to local header file referencesinstead. Another required modification was the manual addition of the Parboil system headerand source files into the project folder directory.4.1.2 SPEC CPUTM 2006SPEC CPUTM 2006 benchmark applications are a set of standard industry computingapplications, designed for stress testing computing architectures [6]. These processing in-tensive applications represent larger industry projects, which tests the scalability of projectcompilation in LLFI. The SPEC CPUTM 2006 benchmark is a proprietary tool provided bythe Standard Performance Evaluation Corporation. The analysis below will use the bzip2benchmark application, which is an implementation of the Burrows–Wheeler data compres-sion algorithm.Operation Average ExecutionTimeResponsiveness Integration withExisting WorkflowGenerateMakefile 10 seconds Fast Select project folderinstead of individ-ual filesCompileToIR 5 seconds Very fast No changeInstrumentation 5 minutes Slow No change, butspeed is signifi-cantly reduced.Profiling 30 seconds Moderate No change5 Results and DiscussionThe objective of this project is to extend the LLFI tool to permit compilation of entireprojects. This objective has been achieved and verified through the use of benchmark appli-cations.The results of the usability analysis show that users can comfortably use existing opera-tions in the LLFI tool on moderately sized projects, with minimal impact to their workflow.However, the instrumentation step continues to be a bottleneck in the fault-injection process.As seen in Table 2, the instrumentation process for large projects such as SPEC CPUTM2006 is slow and the responsiveness is poor as the screen is often locked during its execution.While benchmark applications were suitable for verifying technical aspects of the solution,the principal goal of analyzing usability of the tool remains a challenge. To apprehend the11overall usability of the tool, the complete workflow of a regular user must be fully understood.The implemented solution aims to integrate effortlessly with this workflow.6 ConclusionThe LLFI fault-injection tool has been extended for project compilation through boththe command line interface and the GUI. This extension is important as many industryapplications are organized as project files rather than singular code files. This enhancementprovides the opportunity for industry users to inject faults into industry typical applications.Several alternative solutions were proposed and evaluated with usability in mind. Thesolution to create a custom LLFI Makefile was chosen due to its intuitive integration withthe pre-existing design as well as its flexibility in incorporating user specific options. Theimplemented solution consists of a script to generate a custom Makefile, followed by a directcall to build the Makefile. This script is either directly executed through the command lineor through the project import menu in the GUI.Usability of the implemented design was evaluated with industry standard benchmarkapplications, focusing on the factors of runtime duration, responsiveness and workflow inte-gration. Understanding the user’s workflow remains a major challenge in building an intrinsicdesign.7 Future workWith the LLFI tool extended to compile entire projects, two further enhancements shouldbe considered.• Compilation of project files with multiple directories of source files• Selective compilation of project modulesThe implemented solution operates with the assumption that the source files are organizedunder a flat hierarchy. However, many projects have a hierarchical structure of source files.A possible solution to this problem could involve the recursive creation of Makefiles in eachof the subdirectories and the extraction of shared elements into a Makefile.common file [7].LLFI presently requires an entire project to be compiled into IR prior to performing faultinjections. With the new infrastructure for project compilation in place, featuring modulebased fault-injections will increase the tool’s efficiency and effectiveness for large projects.12References[1] A. Thomas and K. Pattabiraman, LLFI: An Intermediate CodeLevel Fault Injector For Soft Computing Applications. Available:http://blogs.ubc.ca/karthik/files/2013/03/selse-anna.pdf. [Accessed: Sep. 16, 2014].[2] University of Illinois at Urbana-Champaign, LLVM Overview. Available:http://llvm.org/. [Accessed: Nov. 25, 2014].[3] CMake, About CMake. Available: http://www.cmake.org/overview/. [Accessed: Oct.30, 2014].[4] ISTQ Exam Certification, What is Usability testing in software and it’s benefits toend user? Available: http://istqbexamcertification.com/what-is-usability-testing-in-software-and-its-benifits-to-end-user/. [Accessed: Nov. 28, 2014].[5] J. A. Stratton, et al., Parboil: A Revised Benchmark Suitefor Scientific and Commercial Throughput Computing. Available:http://impact.crhc.illinois.edu/Shared/Docs/impact-12-01.parboil.pdf. [Accessed:Nov. 9, 2014].[6] SPEC CPU Subcommittee, SPEC CPU2006 Benchmark Descriptions. Available:http://www.spec.org/cpu2006/publications/CPU2006benchmarks.pdf. [Accessed: Nov.17, 2014].[7] The University of British Columbia, Multiple Makefiles. Available:http://www.ugrad.cs.ubc.ca/ cs219/CourseNotes/Make/multMake.html. [Accessed:Nov. 28, 2014].13Appendix AGenerateMakefile.py#! / usr /bin /env python3”””%(prog ) s takes p r o j e c t source f i l e s as input and gene ra t e s a s i n g l e Make f i l eUsage : %(prog ) s [OPTIONS] <source f i l e s >L i s t o f opt ions :−o <output f i l e >: In te rmed iate r ep r e s en t a t i on ( IR) output f i l e−−r eadab le : Generate human−r eadab le output f i l e−−verbose : Show verbose in fo rmat ion−−debug : Enable debugging symbols−−a l l : Compile a l l source code f i l e s in the d i r e c t o r y .−− f l a g s : Spec i f y add i t i o na l compi le r f l a g s−−help(−h) : Show help in fo rmat ion”””import sys , os , subprocess , t emp f i l es c r i p t p a th = os . path . r ea lpa th ( os . path . dirname ( f i l e ) )sys . path . append ( os . path . j o i n ( s c r i p t pa th , ’ . . / c on f i g ’ ) )import l lvm pathsimport reimport g lobprog = os . path . basename ( sys . argv [ 0 ] )l l vm l i nk = os . path . j o i n ( l lvm paths .LLVM DST ROOT, ”bin / llvm−l i n k ” )c lang = os . path . j o i n ( l lvm paths .LLVM GXX BIN DIR, ” c lang ” )clangxx = os . path . j o i n ( l lvm paths .LLVM GXX BIN DIR, ” c lang++” )bas ed i r = os . getcwd ( )fname = ’ Make f i l e ’newl ine = ’ \n\n ’indent = ’ \n\ t ’opt i ons = {”o” : ”a . out” ,” sou rc e s ” : [ ] ,” readab le ” : False ,”debug” : False ,” verbose ” : False ,” a l l ” : False ,” f l a g s ” : [ ] ,}14de f usage (msg = None ) :r e t v a l = 0i f msg i s not None :r e t v a l = 1msg = ”ERROR: ” + msgpr in t (msg , f i l e=sys . s t d e r r )p r i n t ( d o c % g l oba l s ( ) , f i l e=sys . s t d e r r )sys . e x i t ( r e t v a l )de f ve rbosePr int (msg , verbose ) :i f verbose :p r i n t (msg)de f parseArgs ( args ) :g l oba l opt ionsarg id = 0whi le a rg id < l en ( args ) :arg = args [ a rg id ]i f arg . s t a r t sw i t h ( ”−” ) :i f arg == ”−o” :a rg id += 1opt ions [ ”o” ] = os . path . j o i n ( based i r , a rgs [ a rg id ] )e l i f arg == ”−−r eadab le ” :opt i ons [ ” readab le ” ] = Truee l i f arg == ”−−verbose ” :opt ions [ ” verbose ” ] = Truee l i f arg == ”−−debug” :opt ions [ ”debug” ] = Truee l i f arg == ”−−a l l ” :opt i ons [ ” a l l ” ] = Truee l i f arg == ”−− f l a g s ” :a rg id += 1whi le a rg id < l en ( args ) and not ( args [ a rg id ] . s t a r t sw i t h ( ’− ’ ) ) :opt i ons [ ” f l a g s ” ] . append ( args [ a rg id ] )a rg id += 1arg id −= 1e l i f arg == ”−−help ” or arg == ”−h” :usage ( )e l s e :usage ( ” Inva l i d argument : ” + arg )e l s e :opt i ons [ ” sour c e s ” ] . append ( arg )a rg id += 1i f l en ( opt ions [ ” sour c e s ” ] ) == 0 and opt ions [ ” a l l ” ] == False :usage ( ”No input f i l e ( s ) s p e c i f i e d . ” )de f s e l e c tCompi l e r ( s o u r c eF i l e s ) :15f o r i n p u t f i l e in s ou r c eF i l e s :i f i n p u t f i l e . endswith ( ” . cpp” ) :r e turn clangxxreturn c lang#Build the header f o r the Make f i l ede f i n i t i a l i z eM a k e f i l e ( s o u r c eF i l e s ) :with open ( fname , ’w ’ ) as f out :f out . wr i t e ( ’CC=’ + se l e c tCompi l e r ( s o u r c eF i l e s ) + ’ \n ’ )f out . wr i t e ( ’LINKER=’ + l l vm l ink + ’ \n ’ )f out . wr i t e ( ’OUTPUT=’ + opt ions [ ”o” ] + ’ \n ’ )c f l a g s = [ ’−w ’ , ’−emit−l lvm ’ ] #Defau l t compi le r f l a g sl f l a g s = [ ’−o ’ , ’ $ (OUTPUT) ’ ] #Defau l t l i n k e r f l a g si f opt ions [ ’ r eadab le ’ ] :c f l a g s . append ( ’−S ’ )l f l a g s . append ( ’−S ’ )e l s e :c f l a g s . append ( ’−c ’ )l f l a g s . append ( ’−c ’ )i f opt ions [ ’ debug ’ ] :c f l a g s . append ( ’−g ’ )i f opt ions [ ’ f l a g s ’ ] :add i t i ona lF l a g s = [ ’− ’ + f l a g f o r f l a g in opt ions [ ’ f l a g s ’ ] ]c f l a g s += add i t i ona lF l a g sfout . wr i t e ( ’CFLAGS=’ + ” ” . j o i n ( c f l a g s ) + ’ \n ’ )f out . wr i t e ( ’LINKER FLAGS=’ + ” ” . j o i n ( l f l a g s ) + ’ \n ’ )#Def ine the body o f the Make f i l ede f constructMakeFi le ( s o u r c eF i l e s ) :ob jL i s t = [ ]i f opt ions [ ’ debug ’ ] :f i l e e x t e n s i o n = ’ . bc ’e l s e :f i l e e x t e n s i o n = ’ . l l ’with open ( fname , ’ a ’ ) as f out :f out . wr i t e ( ’SRCDIR OBJS=’ )f o r codeF i l e in s ou r c eF i l e s :o b jF i l e = re . sub ( ’ \ . c$ ’ , f i l e e x t e n s i o n , codeF i l e )ob jL i s t . append ( ob jF i l e )f out . wr i t e ( ob jF i l e + ’ ’ )f out . wr i t e ( newl ine )f out . wr i t e ( ’ bu i ld : ’ )16f out . wr i t e ( ’ $ (SRCDIR OBJS) ’ )f out . wr i t e ( indent )f out . wr i t e ( ’ $ (LINKER) ’ )f out . wr i t e ( ’ $ (LINKER FLAGS) ’ )f out . wr i t e ( ’ $ (SRCDIR OBJS) ’ + newl ine )f o r codeF i l e in s ou r c eF i l e s :o b jF i l e = re . sub ( ’ \ . c$ ’ , f i l e e x t e n s i o n , codeF i l e )f out . wr i t e ( ob jF i l e + ’ : ’ + codeF i l e )f out . wr i t e ( indent )f out . wr i t e ( ’ $ (CC) $ (CFLAGS) ’ + codeF i l e )f out . wr i t e ( newl ine )f out . wr i t e ( ’ c l ean : ’ )f out . wr i t e ( indent )f out . wr i t e ( ’rm −r f ∗ l l ∗bc ’ )f out . wr i t e ( newl ine )de f main ( args ) :parseArgs ( args )i f ( opt i ons [ ” a l l ” ] ) : #Read a l l C/C++ f i l e s in the p r o j e c t d i r e c to ry ,f i l e t y p e s = ( ” ∗ . c” , ” ∗ . cpp” )s ou r c eF i l e s = [ ]f o r f i l e s in f i l e t y p e s :s o u r c eF i l e s . extend ( glob . g lob ( f i l e s ) )e l s e :s o u r c eF i l e s = opt ions [ ” sour c e s ” ]i n i t i a l i z eM a k e f i l e ( s o u r c eF i l e s )constructMakeFi le ( s o u r c eF i l e s )i f name ==” main ” :main ( sys . argv [ 1 : ] )17Appendix BController.java - onClickOpenProject()@FXMLpr i va t e void onClickOpenProject ( ActionEvent event ) {Parent root ;f i l eCount =0;Stage s tage = new Stage ( ) ;DirectoryChooser d irChooser = new DirectoryChooser ( ) ;d i rChooser . s e tT i t l e ( ”Open Pro j e c t Folder ” ) ;F i l e f o l d e r = dirChooser . showDialog ( s tage ) ;i f ( f o l d e r != nu l l ) {System . out . p r i n t l n ( f o l d e r ) ;cur rentF i l ePath = f o l d e r . g e tAbso lu t eF i l e ( ) ;System . out . p r i n t l n ( ” currentProgramFolder : ” + currentProgramFolder ) ;S t r ing command = l l f i b u i l dP a t h+” t o o l s / compileProjtoIRClang −−r eadab le −−a l l −o ” + f o l d e r + ”/” + f o l d e r . getName ( ) + ” . l l ” ;t ry {System . out . p r i n t l n (command) ;Process p = Runtime . getRuntime ( ) . exec (command , nu l l , f o l d e r ) ; ;p . waitFor ( ) ;p . des t roy ( ) ;}catch ( Exception e ){System . out . p r i n t l n ( e ) ;}F i l e [ ] l i s t = f o l d e r . l i s t F i l e s ( ) ;f o r ( F i l e f i l e : l i s t ) {St r ing ext = ge tF i l eExten s i on ( f i l e ) ;System . out . p r i n t l n ( f i l e . getName ( ) ) ;i f ( f i l e . getName ( ) . equa l s ( ”Make f i l e ” ) ){openFi l e ( f i l e ) ;}e l s e i f ( ext . equa l s ( ”c” ) | | ext . equa l s ( ”cpp” ) ) {openFi l e ( f i l e ) ;}}}}18Controller.java - onClickCompileToIr()@FXMLpr i va t e void onClickCompileToIr ( ActionEvent event ) {Parent root ;t ry {boolean f l a g =f a l s e ;c on so l e = new ArrayList<Str ing >() ;tabBottom . getSe l ec t i onMode l ( ) . s e l e c t ( p ro f i l i ngTab ) ;S t r ing cmd = ”echo $ l l f i b u i l d ” ;// Delete the o ld . l l f i l eProce s sBu i lde r deleteCmd = new Proce s sBu i lde r ( ”/bin / tcsh ” , ”−c” , ”rm ” +currentProgramFolder+”/”+currentFileName+” . l l ” ) ;Process d e l e t e = deleteCmd . s t a r t ( ) ;d e l e t e . waitFor ( ) ;d e l e t e . des t roy ( ) ;i f ( currentFileName . equa l s ( ”Make f i l e ” ) ){St r ing command = ”make” ;F i l e f o l d e r = currentF i l ePath ;t ry {Process p = Runtime . getRuntime ( ) . exec (command , nu l l , f o l d e r ) ; ;BufferedReader in1 = new BufferedReader (new InputStreamReader (p .getErrorStream ( ) ) ) ;errorTextArea . c l e a r ( ) ;e r r o r S t r i n g = new ArrayList<>() ;whi l e ( ( l i n e = in1 . readLine ( ) ) != nu l l ) {conso l e . add ( l i n e+”\n” ) ;e r r o r S t r i n g . add ( l i n e+”\n” ) ;}in1 . c l o s e ( ) ;p . waitFor ( ) ;p . des t roy ( ) ;}catch ( Exception e ){System . out . p r i n t l n ( e ) ;}}e l s e{St r ing command = l l f i b u i l dP a t h+” t o o l s / compiletoIR −−debug −−r eadab le −o”+currentProgramFolder+”/”+currentProgramFolder+” . l l ”+currentProgramFolder+”/”+currentFileName ;conso l e . add ( ”$ ”+command+”\n” ) ;Process p = Runtime . getRuntime ( ) . exec (command) ;BufferedReader in1 = new BufferedReader (new InputStreamReader (p .getErrorStream ( ) ) ) ;errorTextArea . c l e a r ( ) ;e r r o r S t r i n g = new ArrayList<>() ;19whi le ( ( l i n e = in1 . readLine ( ) ) != nu l l ) {conso l e . add ( l i n e+”\n” ) ;e r r o r S t r i n g . add ( l i n e+”\n” ) ;}in1 . c l o s e ( ) ;p . waitFor ( ) ;p . des t roy ( ) ;}i f ( e r r o r S t r i n g . s i z e ( )==0){root = FXMLLoader . load ( ge tC la s s ( ) . getClassLoader ( ) . getResource ( ”app l i c a t i o n /compileToIR . fxml” ) ) ;Stage s tage = new Stage ( ) ;s tage . s e tT i t l e ( ”Compiling To IR Result ” ) ;s tage . s e tScene (new Scene ( root , 500 , 150) ) ;s tage . show ( ) ;// Clear f i l eCon t en tf i l eCon t en t = new ArrayList<>() ;S t r ing l i n e ;Fi leReader i npu tF i l e = new Fi leReader ( currentProgramFolder+”/”+currentProgramFolder+” . l l ” ) ;BufferedReader buf fe rReader = new BufferedReader ( i npu tF i l e ) ;//Read f i l e contentswhi l e ( ( l i n e = buf fe rReader . readLine ( ) ) != nu l l ) {f i l eCon t en t . add ( l i n e+”\n” ) ;}programInputText . c l e a r ( ) ;//Clear the Text areaprogramTextArea . c l e a r ( ) ;// Write f i l e content s to Text Areaf i l eConten t Index . setText ( ” Index” ) ;f o r ( i n t i = 0 ; i < f i l eCon t en t . s i z e ( ) ; i++){programTextArea . appendText ( ”\ t \ t ”+f i l eCon t en t . get ( i ) ) ;}F i l e f i l e = new F i l e ( currentProgramFolder+” . l l ” ) ;Path path = f i l e . toPath ( ) ;S t r ing f i leName = path . getFileName ( ) . t oS t r i ng ( ) ;f o r ( i n t n =0;n<f i l eNameL i s t s . s i z e ( ) ; n++){i f ( f i l eNameL i s t s . get (n) . equa l s IgnoreCase ( f i leName ) ){f i l eNameL i s t s . remove (n) ;f i l eNameL i s t s . add ( f i leName ) ;f l a g =true ;break ;}e l s e{}}20i f ( ! f l a g ){f i l eNameL i s t s . add ( f i leName ) ;f l a g = f a l s e ;}i tems =FXCol lect ions . obse rvab l eArrayL i s t ( f i l eNameL i s t s ) ;f i l e L i s t . s e t I t ems ( items ) ;f i l eSe l e cMap . put ( f i leName , f i l eCon t en t ) ;instrumentButton . s e tD i s ab l e ( f a l s e ) ;p r o f i l i n gBut t on . s e tD i s ab l e ( t rue ) ;runtimeButton . s e tD i s ab l e ( t rue ) ;i n j e c t f au l tBu t t on . s e tD i s ab l e ( t rue ) ;tracegraphButton . s e tD i s ab l e ( t rue ) ;showTraceOutputText . s e tV i s i b l e ( f a l s e ) ;}e l s e{root = FXMLLoader . load ( ge tC la s s ( ) . getClassLoader ( ) . getResource ( ”app l i c a t i o n /ErrorDisp lay . fxml” ) ) ;Stage s tage = new Stage ( ) ;s tage . s e tT i t l e ( ”Error ” ) ;s tage . s e tScene (new Scene ( root , 450 , 100) ) ;s tage . show ( ) ;}}catch ( IOException e ) {e . pr intStackTrace ( ) ;System . out . p r i n t l n ( e ) ;} catch ( Inter ruptedExcept ion e ) {// TODO Auto−generated catch blocke . pr intStackTrace ( ) ;System . out . p r i n t l n ( e . getMessage ( ) ) ;}}21

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.52966.1-0103306/manifest

Comment

Related Items