Lab 4 - GCC Build Lab (Part 3)

 Continuing from Part 2

In my previous posts (Part 1 & Part 2), I covered the process of building and installing GCC on the x86-001 server, detailing each step from obtaining the source code to verifying the final build.

Now, I am repeating the same process on aarch64-002, but this time, I will focus on any differences, challenges, and additional tools I used to make the process smoother. The overall steps remain the same, but I encountered some unexpected issues that required troubleshooting.







Setting Up the Environment

Just like before, I needed to set up my workspace by cloning the GCC repository and creating separate directories for the build and installation:

mkdir -p ~/gcc-build-002
cd ~/gcc-build-002
~/git/gcc/configure --prefix=$HOME/gcc-test-002

Once the configuration was successful, I proceeded with the build.







Building GCC: Unexpected Challenges

Building GCC is a resource-intensive process, and on aarch64-002, I faced some unexpected delays.

- On x86-001, the entire build took around 47 minutes.

- On aarch64-002, I noticed that it was taking significantly longer than expected—over 2 hours at one point!


To investigate, I checked system resource usage:

top  # or htop

The CPU was highly utilized, but the build was progressing, just very slowly compared to x86-001.


Solution: Using Screen for Persistent Sessions

Since the long build time made it difficult to stay connected, I decided to use screen to prevent disconnections from interrupting the process.

screen -S gcc-build

After running this command, I started the build:

time make -j 24 |& tee build.log

This allowed me to detach the session (Ctrl + A, then D) and safely close my SSH connection.

Later, I could resume the session anytime with:

screen -r gcc-build

Lesson learned: Screen is extremely useful for handling long builds that may be interrupted!







Installation and Verification

Once the build was complete, I installed GCC using:

make install |& tee install.log

Then, I verified that my custom-built GCC was installed and different from the system version:

which gcc
$HOME/gcc-test-002/bin/gcc --version

Next, I tested it by compiling a simple program:

echo '#include <stdio.h>\nint main() { printf("Hello, GCC!\n"); return 0; }' > test.c
$HOME/gcc-test-002/bin/gcc test.c -o test
./test

If everything was set up correctly, it should print:

Hello, GCC!





Measuring Rebuild and Null Rebuild Times

After installation, I tested the rebuild behaviour:


Step 1: Rebuild after modifying a file

To simulate a source code change, I updated the timestamp of passes.cc:

touch ~/git/gcc/gcc/passes.cc
time make -j 24 |& tee rebuild.log

As expected, the rebuild time was significantly shorter than the initial build.






Step 2: Null Rebuild (No changes)

Finally, I checked how long it takes to detect that nothing needs to be rebuilt:

time make -j 24 |& tee null-rebuild.log

This step was extremely fast because make just verified that everything was already up-to-date.





Reflection

Lab 4 was a deep dive into building and optimizing large-scale software across different architectures. Going through the full GCC build process on x86-001 and aarch64-002, I encountered real-world challenges that forced me to think critically about build performance, system resource management, and efficient workflow strategies.

One of the biggest takeaways was how hardware differences impact build times—even with identical source code and configurations, my build on x86-001 took under an hour, while aarch64-002 exceeded two hours at times. This highlighted the importance of monitoring system resources (top, htop) and anticipating performance bottlenecks when working on cross-platform projects.

Another key lesson was the importance of managing long builds efficiently. Early on, I struggled with SSH disconnections, which made me restart or piece together the build process. Using screen allowed me to detach and reattach sessions, ensuring that my builds continued even if I lost connection. This was a game-changer and is something I will use in any long-running remote job in the future.

Logging and tracking build times also proved to be critical for debugging. At one point, I mistakenly saved logs under the wrong filename (guild.log instead of build.log), making it difficult to verify my build progress. This experience reinforced why precise documentation and validation are essential when working on large software projects.

Lastly, the incremental build and null rebuild tests helped me appreciate how make efficiently tracks changes—modifying just one file resulted in a significantly shorter build time, while a null rebuild completed in seconds. This is a fundamental concept in software development, where optimizing build times can dramatically improve productivity.


Reference

Building GCC Instruction by Professor Chris Tyler's wiki

http://spo600.cdot.systems/doku.php?id=spo600:building_gcc

Comments

Post a Comment

Popular posts from this blog

SPO600 2025 Winter Project - Stage 1: Create a Basic GCC Pass (part1)

Image
 Project Overview The goal of this project is to extend the GCC compiler by adding a custom pass that can analyze the functions being compiled. A GCC pass is a stage in the compilation process that processes intermediate representations (IR) of the source code. These passes perform various optimizations and analyses before generating the final machine code. 📌 What Will This Custom Pass Do? In Stage 1 , I am implementing a GCC pass that: • Iterates through each function in the compiled code. • Prints the function name being analyzed. • Counts the number of basic blocks in the function. • Counts the number of GIMPLE statements inside each function. • Outputs this information to the console. By completing this stage, I will gain hands-on experience with GCC’s internal structures, intermediate representations like GIMPLE , and how to modify GCC’s compilation pipeline. Step 1: Setting Up the Environment 🔹 Note: I have already completed GCC setup ...
Read more

SPO600 2025 Winter Project - Stage 2: GIMPLE Level Clone Analysis and Pruning (part4)

Image
 Progress Summary In this post, I worked on developing a custom GIMPLE-level GCC pass named skim to analyze function clone groups produced by Function Multi-Versioning (FMV). The goal was to determine whether the clones are functionally equivalent at the GIMPLE IR level and output either PRUNE or NOPRUNE . So far, I’ve successfully implemented the initial infrastructure and logic: - Iterated through all functions using `FOR_EACH_FUNCTION` - Classified functions into clone groups using regex to detect `.default`, `.resolver`, and `.variant.*` suffixes - Successfully grouped clones and output the groups to `dump_file` - Verified `.skim` file generation using the `-fdump-tree-skim` compiler flag - Confirmed correct execution of the `pass_skim::execute()` function Now, I aim to extend the functionality to compare GIMPLE IR within clone groups to verify if clones are truly functionally equivalent. Goal Determine at GIMPLE level if functions within each clone group are equivalent, an...
Read more

Lab 1 - 6502 Assembly Language

Image
Introduction In this post, I'll share my experience working on a fun and challenging lab about 6502 assembly language. Assembly language is a low-level programming language, and in this lab, I explored how it works by writing code to manipulate a simple pixel display. My goal was to learn how to calculate performance, optimize code, and modify it to create interesting visual effects on the display. Bitmap Code This code:     - Starts at memory address $0200 (the beginning of the display)     - Loops through all 1536 pixels (6 pages of 256 pixels each)     - Sets each pixel to yellow ($07) lda #$00 ; set a pointer in memory location $40 to point to $0200 sta $40 ; ... low byte ($00) goes in address $40 lda #$02 sta $41 ; ... high byte ($02) goes into address $41 lda #$07 ; colour number ldy #$00 ; set index to 0 loop: sta ($40),y ; set pixel colour at the address (pointer)+Y iny ; increment index bne loop ; continue until done the page...
Read more