OSDev.org

Hello,

I have had to restart my kernel which included rebuilding my development system. I have built a new cross-compiler from binutils 2.25 and gcc 5.1.0. I was able to salvage an earlier version of my printf() function which I knew to have worked properly in a 386 kernel. My cross compiler is built for i686-elf.

I have been looking at the resulting binaries and object files and have noticed that when the printf() function is called, the compiler strips the terminating '\n' character from the string, in particular with the following code:


If I change the code to use my own puts() function, the '\n' character remains and is printed properly. If I rename my printf() function to kprintf(), then the '\n' character remains and is printed properly. No other changes are made to have this character remain in the resulting object.

This is the command I am using to compile the source to .o: i686-elf-gcc -c -O2 -g -ffreestanding -fbuiltin -Wall -Wextra -I/home/adam/src/century/isodir/usr/local/include -o obj/kernel.o kernel.c
I can also confirm that the problem exists at the object file before the objects are linked. I did try to remove the -O2 option which changed nothing.

This seems to be a compiler problem, but I am looking to see if anyone can confirm. Or am I doing something ridiculous?


Thanks in advance for your input.

Adam

I lack a GCC 5.1 at the moment so I can't see what it's doing exactly, but I would expect that it also optimises printf("string without formatters") into a different function call altogether - as long as they're equivalent according to the C standard. This is also why kprintf does not get "optimised"

If you have written your own printf (which strikes me as a good idea for your kernel) why are you telling the compiler to use its built in version of the function?

Thank you. I executed "readelf -a kernel.o" and reviewed it carefully. I noticed in the relocation section that the function names were puts, and not printf. Then doing some digging, I found that puts() -- which I never really use -- appends a '\n' to the end of the string. This is why it was stripping the '\n' character.

So, to your point, the compiler was optimizing printf("string without formatters ending in \n") to use puts(). So, I was doing something really ridiculous.

Good question. I did lift several concepts from the build system and organization from here. Removing the -fbuiltin option creates an error with printf not found (even though I provide my own). I will work on that.

Edit: All good now; thanks for your assistance.