C -complier -options Lab

Before getting into the lab, I must congratulate the Fedora community in finally making the process of setting up the operating system painless. Attempting to install Fedora in the past, I would have to spend some time trying to get my wireless card to work, while other Linux Distros would be good to go out of the box. After installing Fedora 20 on my laptop, I was pleasantly surprised that my wireless network card was ready to connect.

To start the C compliler lab, I needed to install C libraries so I could use the standard libraries, such as #include . However, yum kept returning an error when attempting to install them. After speaking with Professor Tyler, he suggested I turn off SELinux for the yum install; and his suggestion allowed the C libraries to be installed properly. Just don’t forget to turn SELinux back on.

Using a simple Hello, World! C program, we compiled it with the following complier options:

• -g :: enable debugging information
• -O0 :: do not optimize
• -fno-builtin :: do not use builtin function optimizations

Using objdump, and the proper options, we are able to take a closer look at the compiled Hello, World! program. Below are a few of the options we used to take a closer look at the code, and to see what it happening closer to the machine level. You can click on the options to see the output generated:

• -f # display header information for the entire file
• -s # display per-section summary information
• -d # disassemble sections containing code
• --source # (implies -d) show source code, if available, along with disassembly

Looking at the output for the first time, it looked very daunting and may as well been scatches on the wall. And to some degree it still looks that way; however with what we learned in class and spending some time looking at the output, I can see the beginning of some semblance of what is going on. In the output generated with the --source option, where it reads printf("Hello World!\n");, we see:

int main() {
400530: 55 push %rbp
400531: 48 89 e5 mov %rsp,%rbp
printf("Hello World!\n");
400534: bf e0 05 40 00 mov $0x4005e0,%edi
400539: b8 00 00 00 00 mov $0x0,%eax
40053e: e8 cd fe ff ff callq 400410


My interpertation (I am hoping I am right), push %rbp, decreases the stack and places the value of the base pointer into memory, and the following line copies the value on the stack to the base. The line that reads 400534, moves the hex value of 0x4005e0 to the edi register, and then copy the hex value 0x0 to the eax register. Line 40053e calls the printf function (PLT = procedure linkage table?). Hopefully I am right, but if I’m wrong, feel free to let me know.

The lab continues by having us compile the Hello, World! with new options or with the removal of existing options. The first is to add the -static option. Immediatly we can see a difference. The compiled binary without the -static option is 9566B in size; while the binary of the file generated with the -static option is 812710B.

Using objdump with the -d option generates a text file that has 139564 lines, opposed to 183 lines when used against the binary that was complied without the -static option. The -static option prevents the linking of shared libraries, which means those libraries must be compiled with the program. Obviously this is going to have an impact on the size of the binary file, and the objdump file output.

The lab continues by having us remove the -fno-builtin option when compiling. Looking at the objdump with --source option. Looking in the PLT section, instead of printf being pushed, it is a command called puts. Puts is a C command that prints out a string with a new line. Since we are calling the printf function to display a string with a new line, it is more optimal (as the complier sees it) to use puts instead of printf.

Next, we remove the -g option when compling with GCC. This excludes debugging information from from the binary, causing the the output to be smaller. We can see the removal of the debug sections by using objdump with the -s option. The debug information would normally be at the bottom, however it is missing from this. This would explain the size difference in the binary.

Step 4 of the lab has us look at how values are loaded into the registery (order of the registries are used. It seems that they are loaded into registries in a specific order. Here are a few excerpts at various counts:

• One Arguement:
mov 0x200abb(%rip),%eax # 601034 =a=
• Three Arguements:
mov 0x200acf(%rip),%ecx # 60103c =c=
mov 0x200ac5(%rip),%edx # 601038 =b=
mov 0x200abb(%rip),%eax # 601034 =a=
• Ten Arguements:
mov 0x200b1c(%rip),%r10d # 60105c =j=
mov 0x200b0d(%rip),%r9d # 601054 =i=
mov 0x200b02(%rip),%r8d # 601050 =h=
mov 0x200af8(%rip),%edi # 60104c =g=
mov 0x200aee(%rip),%esi # 601048 =f=
mov 0x200ae4(%rip),%ebx # 601044 =e=
mov 0x200ad9(%rip),%r11d # 601040 =d=
mov 0x200acf(%rip),%ecx # 60103c =c=
mov 0x200ac5(%rip),%edx # 601038 =b=
mov 0x200abb(%rip),%eax # 601034 =a=


WordPress seems to have an issue display greater than and less than signs (even with code tags), so the = = are less than and greater than signs. You can find a sample output here. It seems the order that the registers are used is eax, edx, ecx, r11d, ebx, esi, edi, r8d, r9d, r10d — perhaps the next incarnation of assemly should display it as like r1, r2, r3, … ?

The subsequence instructions for this lab has us use the printf fuction outside of the main() code; and changing the optimization level from 0 to 3 (-O0 to -O3). The output of objdump for the former is thus. We can see a section of assembly specifically for the function that was created, and the call for it in the “main()” section. This gave me insight to this part of the assembly code:
400540: 55 push %rbp
400541: 48 89 e5 mov %rsp,%rbp
Each time a function is called (both main and outhw), these two lines appear. This seems to move the current base pointer onto the stack, and replaces it with the value of the stack pointer for processing. Then the following lines:
400553: 5d pop %rbp
400554: c3 retq
returns the main function on the stack back to the bp for further processing.

Lastly, we changed the optimization level from 0 to 3. We can see a significant change when using objdump with the –source option. Compared to -O0 option, the main part of the program has been shifted sooner in the output. It is also only 7 lines opposed to the 15 lines in the original compliation. This is mostly due to the removal of moving things onto and off the stack. The GCC optimizer seems to have noticed that it does not need to create a a stack to execute the binary and complied it without the use of it.

After completing this lab, I have never appreciated the C complier more.

-Richard K.

SPO600 Code Review Lab

The 1 of 2 picks for this lab is soundconverter. It is on a GPLv3 license, and their homepage can be found here.

Soundconverter uses launchpad to track their bugs, along with other features it provides to the community. While navigating that site, I was able to locate two bugs that were fixed by patches provided by members of the community; it seems in one of their translations, not everything in the GUI was translated to Hungarian from english – you can find the complete bug here.

The bug submitter is also the bug resolver (patch provider). Upon writing the patch for it, he was requested to paste it in the bug comments or “create a pull request on github”. This bug was resolved in two days, and the patch is available through the link in the comments, and under the Patch link on the right hand side. There also seems to be an option to add a patch to this bug, but requires a launchpad account.

The 2 of 2 pick for this lab is xfce4-xkb-plugin, which is licensed under BSD. The webpage for this package is here. While this package relates to keyboard layouts, XFCE provides an entire desktop interface for many Linux distributions including Fedora.

They use the all too familiar Bugzilla for their bug tracking system. Since they maintain so many packages, one can spend a day and forever going through it all. I was able to find a bug resolved with a patch. This bug involved updating an out of date library with a newer library. A community member provided the patch and Jesper Karlsson applied the patch to the master branch in git – 2 years later (according to the time stamps).

It seems both use similar processes. In both cases, the bug reporter was the same person supplying the fix to the bug. While in the first case, with soundconverter, the reporter received a reply within a day, and had their fix promptly applied, the latter took 2 years to reply (perhaps the fix was applied earlier but he never responded? – either way it was a long time).

Assuming the maintainers are available and regularly check active bugs, allowing members to create a bug and submit a fix for it right away could save many people from headaches. It would allow others who experience the same issues to quickly get resolutions or even contribute to the fix by looking at the available patch; having multiple eyes on the code helps keep it efficient and clean.

A disadvantage to this approach is that untested “fixes” is available for everyone before being fully vetted.

There is also a large list of bug reports that go unresolved from looking at the bug list on XFCE, and in the comments you can read it was “closed” from a mass old bug sweep that told users “if it was still an issue, the bug should be reopened”.

Overall the processes seem to work for anything major or critical, but some of the minor issues, or only affecting a small group of people may not see any attention.

-Richard K.