Lab-4: GCC Build Lab - Building the GCC Compiler from Source

Introduction

In this lab, I explored the process of building a large software project—specifically, the GCC (GNU Compiler Collection) compiler—from source code. GCC is a critical toolchain used for compiling programs in various programming languages, including C, C++, and Fortran. The goal of this lab was to understand the build process, use tools like make and autotools, and compare the performance of the build process on two different architectures: x86-001 (x86_64) and aarch64-002 (ARM64). This lab is part of the SPO600 course, where we study software portability and optimization.

Lab Steps and Results
1. Obtaining and Building GCC

I followed these steps to build GCC on both servers:

  1. Cloned the GCC source code:
    git clone git://gcc.gnu.org/git/gcc.git gcc-source


  2. Created a separate build directory and configured the build:
    mkdir gcc-build
    cd gcc-build
    ../gcc-source/configure --prefix=$HOME/gcc-install --disable-multilib

  3. Built GCC using make:
    time make -j 16 |& tee build.log

  4. Installed GCC:
    make install

2. Build Times

Server             Initial Build Time           Rebuild Time                           Null Rebuild Time
x86-001            14m 43.132s                 1m 52.908s                                 1m 9.318s
aarch64-002  72m 23.931s                  4m51.450s                                  2m3.145s

Observations:
  • The ARM64 server (aarch64-002) took significantly longer to build GCC compared to the x86_64 server (x86-001). This is likely due to differences in CPU performance and architecture.
  • The rebuild time after modifying passes.cc was much shorter, as only the affected files were recompiled.
  • The null rebuild was almost instantaneous, as make simply checked the timestamps and determined that no changes were needed.
3. Proof of Successful Build
  • Verified the GCC version:
    $HOME/gcc-install/bin/gcc --version

    Output:
    gcc (GCC) 13.0.0 20231003 (experimental)

  • Compiled and ran a simple C program:
    echo 'int main() { return 0; }' > test.c
    $HOME/gcc-install/bin/gcc test.c -o test
    ./test

    The program ran successfully, confirming that the GCC build works.
4. Comparison with System GCC
  • The system GCC version on both servers:
    /usr/bin/gcc --version

    Output
    gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10)

  • The newly built GCC is a development version (13.0.0), while the system GCC is an older stable version (8.5.0).

Experiences and Reflections

1. Challenges:
  • The initial build took a long time, especially on the ARM64 server. Patience was key!
  • I encountered a missing dependency (libmpc-devel) during the configuration step, but installing it resolved the issue.
2. Learnings:
  • I gained a deeper understanding of how large software projects are built using tools like make and autotools.
  • I learned how to use the time command to measure build times and the tee command to log output.
  • I now understand the importance of separating source and build directories to keep the source tree clean.
3. Interesting Observations:
  • The rebuild process was much faster than the initial build, demonstrating the efficiency of make in handling incremental builds.
  • The null rebuild was almost instantaneous, highlighting how make optimizes the build process by checking file timestamps.

Conclusion
This lab was a great hands-on experience in building a large software project like GCC. I learned how to configure, build, and install software from source, and I gained insights into the differences in build performance across architectures. The lab also reinforced the importance of tools like make in managing complex builds efficiently. I look forward to applying these skills in future projects and exploring optimization techniques in the SPO600 course.

Comments

Post a Comment

Popular posts from this blog

Lab-1: Exploring 6502 Assembly

Image
Introduction This lab focuses on using the 6502 emulator to understand assembly language by manipulating a bitmapped display. The goal is to fill the screen with colors, optimize the code for better performance, and experiment with various modifications to observe visual effects. Through this lab, we learn about addressing modes, loop structures, and how execution time and memory usage are calculated in a 6502-based system. Performance Analysis We used an online 6502 emulator since physical hardware wasn't available. The lab required analyzing and manipulating an initial code sample to achieve specific objectives. Here's the original code: At first glance, this sequence of instructions seems daunting. However, once broken down, it becomes quite logical. The code fills a 1024-pixel bitmap display with yellow (color code #$07) by iterating through all four 256-byte pages of the display. Below is the output from the emulator after running this code: Task 1: Calculate Execution Tim...
Read more

Project Stage III: Multi-Clone Analysis in GCC Pass

 Introduction In Stage III, I enhanced my GCC pass to analyze programs with multiple cloned functions simultaneously, making individual PRUNE/NOPRUNE decisions for each clone. This involved refining GIMPLE code comparisons, handling compiler optimization challenges, and validating results on both x86_64 and aarch64 architectures. Implementation Core Logic (Key Code Snippets) 1. Data Structure for Clones // Stores GIMPLE statements and operand types for each function struct GimpleStmtInfo { int code; std::vector<tree> operands; }; std::map<std::string, std::vector<GimpleStmtInfo>> function_map; 2. Clone Detection // Identify cloned functions by name (e.g., "func.clone1") if (func_name.find(base_name + ".") == 0 && func_name.find(".resolver") == std::string::npos) { // Compare GIMPLE sequences bool is_same = (base_gimple == cloned_gimple); fprintf(dump_file, "Result: %s\n", is...
Read more

Lab 2 - 6502 Math Lab

Introduction In this blog post, I will share my experience working on the second lab of the SPO (Systems Programming and Operating Systems) course. The goal of this lab was to create a subroutine in 6502 Assembly Language that draws an image on a bitmapped screen and then animate it by making it bounce around the screen. The lab involved writing code to move a graphic diagonally across the screen and then modifying it to make the graphic bounce off the edges of the screen. The Code   The initial code provided draws a 5x5 pixel image (either an "O" or an "X") on the screen and moves it diagonally from the top-left corner to the bottom-right corner. The image is cleared and redrawn in a new position to create the illusion of movement. The code uses a delay loop to slow down the animation so that it is visible to the human eye. Here is the initial code: ; ; draw-image-subroutine.6502 ; ; This is a routine that can place an arbitrary ; rectangular image on to the scree...
Read more