Cosmos compilation-C # open-source operating system Learning Series 2

Http://www.cnblogs.com/li0803/archive/2011/02/03/1948924.html

I am afraid that I will put my younger brother's first analysis work in fear. I hope you will forgive me and provide comments and suggestions.

1. Before startup

The convenience of vs also masks the process of converting an operating system from source code to a binary file. Therefore, we should first start with source code compilation, first, find out how vs compiles C # source code into a binary code that can be started with guidance.

The source code package used by the user is cosmos-72205.zip.

For vs, you need to install the vs2010 SDK.

Ii. msbuild

Anyone who has compiled Linux should be familiar with the make file. Here we can clearly see the process of compiling C source code into binary source code using the compiler, everything you have done in the middle can be clearly seen. However, friends who use vs usually run F5 directly after the program is written. We do not know what to do later. For the source code of Cosmos, vs only helps us compile the code into Il, which cannot be run in the absence of CLR environment. Therefore, vs also needs to compile the Il code into local code for the CPU. The intermediate process is controlled by msbuild. For msbuild introduction, you can directly view the msdn documentation. In general, this is equivalent to the status of make files. It guides vs to generate binary files that can be guided.

3. Compile Cosmos

First, run the build/vsip/install. BAT file in the decompressed folder, which seems to be used to install the cosmos compiling environment. After the installation is complete, double-click the source/cosmos. sln file (install vs2010 SDK before this) to view all source code files (Excited ~~~~ The main reason for selecting COSMOS ). After opening the project, you must first change it to the breakpoints project. Then you can directly start F5. After the cosmos compilation is complete, the virtual machine under the built-in bulid directory is directly used to load the compiled ISO file and run it. The running interface is as follows:

Iv. Cosmos compilation process

We can see that the project is not set as a general C # project, but a cosmos project, which is running build/vsip/install. install bat in vs2010, and call the msbuild file of the project to control the compilation process. You can find a cosmos.tar get file under the c: \ Program Files \ msbuild \ cosmos directory, open it with a WordPad and find the following content:

<Usingtask taskname = "Cosmos. Build. msbuild. il2cpu" assemblyfile = "$ (vsipdir) \ cosmos. Build. msbuild. dll"/>
<Usingtask taskname = "Cosmos. Build. msbuild. NASM" assemblyfile = "$ (vsipdir) \ cosmos. Build. msbuild. dll"/>
<Usingtask taskname = "Cosmos. Build. msbuild. makeiso" assemblyfile = "$ (vsipdir) \ cosmos. Build. msbuild. dll"/>
<Usingtask taskname = "Cosmos. Build. msbuild. LD" assemblyfile = "$ (vsipdir) \ cosmos. Build. msbuild. dll"/>
<Usingtask taskname = "Cosmos. Build. msbuild. readnasmmaptocosmosmap" assemblyfile = "$ (vsipdir) \ cosmos. Build. msbuild. dll"/>
<Usingtask taskname = "Cosmos. Build. msbuild. extractmapfromelffile" assemblyfile = "$ (vsipdir) \ cosmos. Build. msbuild. dll"/>

Personally, these DLL files should be loaded into the memory during the compilation of the cosmos project. In the source code of the cosmos project, you can find that all the DLL files are directly or indirectly inherited from the appdomainisolatedtask class. View msdn, this class that inherits this class has rewritten the execute method, msbuild should automatically run the execute method inherited from the appdomainisolatedtask class in these sets (the running order does not seem to follow the writing order above ), next, we only need to analyze every execute method, you can understand how the C # source code program is compiled into a local CPU binary file (the parameters required for running the above classes can be found in the following part of the file, as shown below:

<IL2CPU  DebugMode="$(DebugMode)"
                 TraceAssemblies="$(TraceAssemblies)"
                 DebugCom="1"
                 UseNAsm="true"
                 References="@(ReferencePath)"
                 OutputFilename="$(TargetDir)$(MSBuildProjectName).asm"
                 EnableLogging="true"
                 EmitDebugSymbols="$(DebugSymbols)"/>

         <NAsm    InputFile="$(TargetDir)$(MSBuildProjectName).asm"
                 OutputFile="$(TargetDir)$(MSBuildProjectName).obj"
                 IsELF="$(IsELF)"
                 ExePath="$(NasmFile)" /> 

          <!--ELF only--> 
        <Ld      CosmosBuildDir="$(CosmosDir)\Build"
                 WorkingDir="$(TargetDir)"
                 Arguments="-Ttext 0x500000 -Tdata 0x200000 -e Kernel_Start -o '$(TargetDir)$(MSBuildProjectName).bin' '$(TargetDir)$(MSBuildProjectName).obj'"
                 Condition="$(IsELF) == 'true'"/>

        <Delete Files="$(TargetDir)$(MSBuildProjectName).obj" Condition="$(IsELF) == 'true'"/>

        <ExtractMapFromElfFile  InputFile="$(TargetDir)$(MSBuildProjectName).bin"
                                DebugInfoFile="$(TargetDir)$(MSBuildProjectName).cpdb"
                                WorkingDir="$(TargetDir)"
                                CosmosBuildDir="$(CosmosDir)\Build"
                                Condition="$(IsELF) == 'true'"/> 

        <CreateItem Include="$(TargetDir)$(MSBuildProjectName).bin" Condition="$(IsELF) == 'true'">
            <Output TaskParameter="Include"
                    ItemName="TempFilesToCopy"/>
        </CreateItem>

        <Copy SourceFiles="@(TempFilesToCopy)"
              DestinationFiles="@(TempFilesToCopy->'$(TargetDir)\%(Filename).obj')"
              Condition="$(IsELF) == 'true'"/>
        <Delete Files="$(TargetDir)$(MSBuildProjectName).bin" Condition="$(IsELF) == 'true'"/>

         <!--End of ELF only-->

          <!--binary only--> 
        <ReadNAsmMapToCosmosMap InputBaseDir="$(TargetDir)"
                                DebugInfoFile="$(TargetDir)$(MSBuildProjectName).cpdb"
                                Condition="$(IsELF) == 'false'"/>
         <!--end of binary only-->


         <!--todo: update cxdb to cxdbg--> 

        <MakeISO InputFile="$(TargetDir)$(MSBuildProjectName).obj"
                 OutputFile="$(TargetDir)$(MSBuildProjectName).iso"
                 CosmosBuildDir="$(CosmosDir)\Build" />）。

4.1 start with Cosmos. Build. msbuild. il2cpu.

Cosmos. Build. msbuild. il2cpu inherits from the appdomainisolatedtask class, overwrites the execute method, and calls the execute method of the instantiated il2cputask class in the execute method. The execute method of the il2cputask class is used to obtain the entry point of the program and read all Assembly files. For this level, the il2cpu compiler is too complex. For the following analysis, read it from a critical perspective: after reading the Assembly file, the il2cpu compiler should be called to convert the Il code to the assembly code file of the local CPU. ASM and symbolic files supporting debugging. cpdb. By now, the cosmos. Build. msbuild. il2cpu task has been completed. The subsequent tasks are handled by cosmos. Build. msbuild. NASM.

4.2 cosmos. Build. msbuild. NASM

The compile (a cross-platform compilation and Development Tool) tool converts the previous step. the ASM file is compiled into the ELF format (for details about the ELF format, see another article http://www.cnblogs.com/li0803/archive/2010/11/15/1877961.html in the younger brother space) target file. OBJ, to this cosmos. build. msbuild. the work of the NASM class is also over. build. msbuild. makeiso class for processing

4.3 cosmos. Build. msbuild. makeiso

The. OBJ file generated in the previous step is linked to an ISO file so that the virtual machine can load and run it. In fact, a cosmos operating system file can be run at this step, but only an ISO file can be obtained. It can only be run on virtual machines and cannot be installed on actual machines, it is not convenient to debug, so Cosmos also needs msbuild to do something to generate one. bin binary files and some support for debugging the source code of the operating system in. cpdb symbol table file. I don't know if this is true or not. If it is not true, I hope you can correct it :)

4.4 cosmos. Build. msbuild. LD

The fuse tool is linked to an independent binary file that runs on the local CPU in the ELF format (for compilation and link, refer to "Programmer self-cultivation"), and then handed over to Cosmos. build. msbuild. extractmapfromelffile

4.5 cosmos. Build. msbuild. extractmapfromelffile

To process the files generated in the previous step. The younger brother is also the first contact with objdump.exe. From the source code, it should be compiled from the previous step. binfile, and then generate a file that supports debugging. the cpdb symbol table file will be handed over to Cosmos. build. msbuild. readnasmmaptocosmosmap performs the final processing.

4.6 cosmos. Build. msbuild. readnasmmaptocosmosmap

Cosmos. build. msbuild. the readnasmmaptocosmosmap class directly inherits from the appdomainisolatedtask class and overwrites its own execute method, which is generated from the NASM task. in the OBJ file, read and retrieve the address symbol ing table (what? Not familiar), write it into the built-in Firebird Database for easy source code tracking and debugging.

By now, the compilation of cosmos has been completed.