Lab2B: Building glibc

     For part B of Lab 2 I was tasked with building my own version of glibc and then introducing a bug into it to ensure I am using my build instead of the installed version. Glibc is GNU's implementation on the standard C Library which underpins many functions of the Linux kernel, so it is very important that my build and tests don't affect the systems version of glibc or my classmates will not be happy with me.

      The first step is to get the source code for glibc. Since I used wget and tar for part A, I will use git this time to get a feel for both methods. So running git clone git://sourceware.org/git/glibc.git gave me the source code to build from but before I did there is an important step for glibc which is to create a separate directory to build in as glibc uses two parallel trees for source and build codes. This is nice so that if I have messed up my build I can just clear out that directory and still have the source code to start my build again without having to go get the source code again.

      To build glibc in my build directory I had to call the configure from the source directory: ~/src/glibc/configure -prefix=/usr. I was lucky and all required packages were already installed so a Makefile was successfully created and I was ready to build. I wasn't thinking and ran a simple make which resulted in a roughly 40 minute process, if I had thought a bit longer I would ahve used the -j option to take advantage of the core count available on AArchie. But the make was successful and I now have the executable I need to test my build, testrun.sh.

      For testing, I have changed the clock() function to just return 1 so by creating a simple program calling the clock function I can see if my glibc is being used.

 #include <stdio.h>
#include <time.h>

 int main() {
             printf("Broken Clock Says: %d\n", clock());
}
     By running the a.out with build/glibc/testrun.sh it returns Broken Clock Says: 1. Just to be sure I ran it again with the installed glibc and it returned 1133 so I know for sure that my build was successful and my program ran using it.

      Multiarch or Multiple Architectures, refers to software that is designed to run on more than one computer architecture. Glibc leverages multiarch in two ways. Firstly it is itself a multiarch software in that it has support for a variety of architectures like aarch64, arm and x86_64. Since this is case, the second multiarch aspect of glibc is C code that is compiled with it can be run on any of its supported architectures. This flexibility is one of the reasons it has been adopted so widely.

      Overriding for software generally means superseding the default functionality of the code with your own implementation. For glibc, overriding supports it's multiarch design by changing the implementations of certain functions based on the environment that it is deployed in. Overriding also allows glibc users to tailor default functions to suit their specific needs for better performance.

Comments

Post a Comment

Popular posts from this blog

Lab 1: Investigating Open Source Development

     While most people today have at least heard of Open Source software, many people, myself included, don't know a lot about how the development process works or how these communities are structured and managed. Today's post will explore these topics in reference to two Open Source projects from different licences, Privacy Badger under the GNU General Public License and Deeplearning4j under the Apache2.0 License. Privacy Badger:      Privacy Badger is a browser extension aimed at striking a balance between a user's right to privacy and content providers' business interest. By only blocking ads and cookies that ignore the Do Not Track setting of the user's browser, thus as long as a content provider isn't hosting those types of ads they won't lose out on ad revenues.      Privacy Badger is run primarily off of its GitHub repository (link below) and it seeks to make contribution easy by keeping a list of desired issues to tackle that are publicly avail
Read more

Lab 3: Compiled C Code

Image
     In this lab I investigated the transformation of my code from source C code to C compiler output to learn exactly what the compiler is doing when I call it. My initial program was a simple Hello World program: #include <stdio> int main(){         printf("Hello World!"); }      My first compilation was a simple gcc with most of the optimization and fancy tricks stripped out. This was done with the -O0 and -fno-builtin flags, -O0 meaning do not use any optimizations when compiling and -fno-builtin meaning do use any built in function optimizations. So : gcc -g -O0 -fno-builtin -o hello1 hello.c.       The compiler then returns an Executable and Linkable Format file (ELF for short) named hello1 which I used to examine what it had done to my code. The first thing I noticed after using objdump to look at the assembly code that was output was that my simple four line program had ballooned out to 199 lines which led me to wonder how much bigger my elf fi
Read more

Lab 4: Assembler

     When first starting this lab I was excited to dive in to assembler as it gives a granular understanding of all steps involved in processes that are taken for granted in higher level languages. So after reading through the basic instructions used in assembler I began on the task of writing a program that loops from 0 - 30 printing "Loop: X" with X being the current loop count.      I immediately realized the significant difference between assembler and every other language I have coded with before. Instead of simply declaring variables and doing calculations however I want and dumping the results to the screen, its important to line all of the data I want up before executing any command and this lab really highlights this process. So we know the end result is a printed string 30 times, step 1 of which is getting a string to print. I created a .data section to hold both my string and the length of that string. This is important because unlike in C I can't replace X w
Read more