OSDev.org

Greetings all.

Well I have poured over forums and such and one thing that I was successfully able to do in 32 Bit windows was make a bootable OS ( Basic Kernel ) with NASM and GCC. The kernel loaded and everything worked great.

Now.. I am on Windows 7 X64 and boom, I ran into all the PE blah blah that DJGPP and regular 32-Bit MinGW just doesn't work with. So I had to switch over to MinGW64. I soon realized I needed to build a Cross Compiler, of which I successfully compiled and it works. I am even able to compile all my OS code with no errors.

Now the problem. It bloats the kernel file when I go to link it. So the kernel file doesn't run correctly under my "Toy" version of an OS. I am trying this without grub support.

The Kernel is little over a meg because of the added libs that the cross compiler adds to it. I am using the i586-elf-gcc.exe cross compiler.

My switch is set as :

This makes it an object
i586-elf-gcc -fstrength-reduce -fomit-frame-pointer -nostdinc -fno-builtin -ffreestanding -c -o kernel.o kernel.c

This is to link it
i586-elf-ld -T linker.ld --oformat binary -o kernel32.sys start.o kernel.o

There is an assembly language part that is compiled as start.o
nasm -f coff -o start.o start.asm

But apparently I am missing something here as I am used to DJGPP command line argument structure.

Again, it compiles with no errors, but it will not work correctly because of the conflicting libs and so it bloats it. I am making my own libs. And that is accounted for in my OS when I compile this under DJGPP.

Thanks for any help / suggestions offered.

EDIT UPDATE : I should have mentioned this... GCC 4.8.1 ( I compiled this with MinGW to make the Cross Compiler version of GCC )

EDIT UPDATE 2 : I believe I have fixed all my typo errors here. Sorry for any confusion.

I finally FOUND the answer. OH MY !!!


OK.. once I knew WHAT to look for, I was able to find a website that had a Texas Instrument version of GCC. Well it listed command line areguments. So I was on the hunt when I traced it back to the source of GCC and sure enough.. the answer was there.. barried in thousands of lines of command line switches.


i586-elf-gcc -Ofast -ffreestanding -c -o kernel.o kernel.c

This is all I needed.

Turns out that since -ffreestanding only disables standard libraries, and even the cross compiler tut said it wont get rid of all libraries, so I had to find another way to optimize everything down. -Ofast was the OTHER switch I needed !!!!

So there we have it. Finally I can compile under Windows 7 64-Bit. SWEET !

Now back to work on my OS.

If the problem is that it's linking in extra libraries, changing the call to gcc (during compilation) shouldn't change that, since the -c flag means it doesn't link. Passing arguments (such as -nostdlib) to ld is what will prevent it from linking in libraries. That, and your linker script file are most likely whats causing the compiled kernel file to be so large, not the optimization level.

-JL

Please read these wiki tutorials:

http://wiki.osdev.org/Bare_Bones
http://wiki.osdev.org/Why_do_I_need_a_Cross_Compiler%3F

They document a few things I think you should know about how to use cross-compilers properly. I'm tired now, but in short: Link with your compiler, don't link with ld. -nostdinc is bad. -fno-builtin is implied by -ffreestanding, so you don't have to pass that. You are mixing COFF/PE and ELF - You seem quite confused which binary format you are using. You may wish to make a PE cross-compiler, if that exists - or just embrace ELF. If you need a particular optimization level to build a correct kernel, you are doing it wrong. Fix whatever makes other optimization levels not work. You appear not to be using libgcc, which gcc expects you to use, regardless of whether you do that or not. [and so on, read the tutorials for more context and see some of my older posts on the topic]

sortie wrote:Please read these wiki tutorials:

http://wiki.osdev.org/Bare_Bones
http://wiki.osdev.org/Why_do_I_need_a_Cross_Compiler%3F

They document a few things I think you should know about how to use cross-compilers properly. I'm tired now, but in short: Link with your compiler, don't link with ld. -nostdinc is bad. -fno-builtin is implied by -ffreestanding, so you don't have to pass that. You are mixing COFF/PE and ELF - You seem quite confused which binary format you are using. You may wish to make a PE cross-compiler, if that exists - or just embrace ELF. If you need a particular optimization level to build a correct kernel, you are doing it wrong. Fix whatever makes other optimization levels not work. You appear not to be using libgcc, which gcc expects you to use, regardless of whether you do that or not. [and so on, read the tutorials for more context and see some of my older posts on the topic]

piranha wrote:If the problem is that it's linking in extra libraries, changing the call to gcc (during compilation) shouldn't change that, since the -c flag means it doesn't link. Passing arguments (such as -nostdlib) to ld is what will prevent it from linking in libraries. That, and your linker script file are most likely whats causing the compiled kernel file to be so large, not the optimization level.

-JL

Thanks for the response guys. Little late now though since in my 2nd post I had mentioned that I solved the problem and I explain what I did to fix it. But thanks for trying.

@ piranha, I totally agree. I figured that out. What surprised me though is that there are soooooo many options for many levels of optimization. I was very surprised. But at least everything works now.

@ Sortie, I totally agree with you on those command line switches. It's why I removed those. I found it out shortly before I posted my 2nd post. Your right on the money there. As for LD, it works fine for what I am doing. Thanks for the tip though. And the links your showing about making the cross compiler is what I had already successfully made. I'm Guessing you missed that point in my OP. Again though, thanks for the reply. You guys rock !!!


EDIT UPDATE : I will be making a youtube video sometime this week to share what the steps are that I took to get this to work on Windows 7 x64. I couldn't find any on youtube and reading pages and pages and pages of websites is a real pain at times. lol So I'll be making this video more for me to remember then anything. But I hope to share the knowledge for others too.

-Ofast was the OTHER switch I needed !!!!

This is oh so wrong, but you seem ignorant enough to not pay any attention.

Linking libgcc is not necessary per se. That is, if you're willing to write some additional support functions yourself.
I don' t use libgcc, and the only things my kernel needs from it are __divdi3 and IIRC __moddi3, which I implemented myself.

But do build a proper cross-compiler. It'll save you heaps of trouble. If you find the steps involved long winded, and don't want to have to repeat them, write a shell script, since you'll either be using MinGW or Cygwin on Windows, which both support shell scripts.

Kortath:

You are supposed to link with the compiler, not the linker. This gives the compiler a chance to do things before invoking the linker, but it also allows the compiler to rewrite the link line and add compiler-specific directories to the search path, for instance such that -lgcc works as expected. The reason I linked you to these tutorials was not so you could follow then, but to show you how to properly use a cross-compiler. Notice, for instance, how the Bare Bones tutorial link with the compiler and use libgcc. You are likely to run into trouble if you don't follow the instructions carefully. Take a few extra moments to think about how these tutorials use the cross-toolchain and whether you are doing the same.

Perhaps you should reconsider doing a youtube video. It'll likely be out of date soon as the osdev community recommendations for cross-compiler usage tends to change over time. Additionally, if you make any errors or omissions, nobody else can correct them and you contribute to spreading false information that leads to more posts like this. Finally, if you fail to read a tutorial in text on a wiki because your attention span is too short, you should in no way be making an operating system, and so shouldn't people that decide to use the video tutorial over a community edited wiki. I also recommend that you wait a couple years before making a tutorial for newbies, as newbies making tutorials for newbies can only go horribly wrong. Do feel free to contribute to existing tutorials, though.

halofreak1990:

The compiler doesn't give a **** whether you are using libgcc or not. It'll use it if it feels like it. You are breaking an important ABI and compiler contract if you are not using it. The compiler expects to be able to use anything in its libgcc for any purpose. There is no "You only need libgcc if you do 64-bit division on a 32-bit platform" rule. What you are describing is that in your experience, you haven't seen any other libgcc calls. That doesn't mean they don't exist. Perhaps if you declare three ints called foo, bar and baz as global variables, then it emits some special __libgcc_there_are_foo_variables call into libgcc. Yes, that's a silly example - but can you prove that doesn't happen? You haven't read the gcc source code so you don't know if it emits such calls under weird circumstances. Additionally, your users (or yourself) may be using a newer compiler that emits more calls. Basically, you are begging for trouble when the compiler decides to do something different than it currently does, which it some day will. In short, you are guilty of these compiler crimes:

• Lying to the compiler: The compiler thinks it has libgcc, there is no option "You don't have libgcc", therefore you told it that it has libgcc, but you didn't link with libgcc.
• Not cooperating with the compiler: The compiler has nicely provided libgcc for you as its part of the compiler, you just have to link it in. Instead, you choose to reimplement it yourself, probably poorly. The compiler wants control of what libgcc contains, but you are taking that away by reimplementing it.
• Not controlling the compiler: You don't want to use libgcc, but you didn't modify gcc such that it disables all calls to libgcc and throws compile errors instead, or perhaps by expanding the code generation such that it inlines what libgcc would have contained. You haven't made sure that only __divdi3 and __moddi3 calls could ever happen by studying the gcc source code.

Additionally, you are guilty of laziness as it is really simple to just build libgcc along with the cross-compiler and link it in by adding -lgcc to the end of the link line. All the wiki tutorials show how to do this properly. Your verdict is that your toolchain breaks and you'll try to reimplement more libgcc functions and that in the future you'll fail to compile old versions of your operating system.

I do not want any libs, or libcc or any of that. The switch is all I needed. But thanks for the input.

You do realize that libgcc is part of gcc, right? If you don't use that, it's equivalent to commenting out a couple hounded lines of gcc and hoping you can still compile all programs correctly. All code generated by gcc needs libgcc, even though some particular code gcc generates may not need it. It's even a static library, so you just supply it, and it only links in the particular functions you need. You need libgcc because.. it's the right way. That's how it works.

sortie wrote:You do realize that libgcc is part of gcc, right? If you don't use that, it's equivalent to commenting out a couple hounded lines of gcc and hoping you can still compile all programs correctly. All code generated by gcc needs libgcc, even though some particular code gcc generates may not need it. It's even a static library, so you just supply it, and it only links in the particular functions you need. You need libgcc because.. it's the right way. That's how it works.

Yes, I am totally aware. I am making my own libs and remove any and all other libs. That switch that I needed allows me to do this very thing. And what C code I have, does work now the way I intended it too. If I was making a full fledged OS, then yea I can see your point of "doing it the right way" as you put it. But I am not making a full OS. Just something on a very limited bases. So what I am doing is exactly what I needed it to do. And as I stated, the whole purpose of this thread was not to argue about what is right or wrong, but about finding a way to remove those libs. I did find a way, so this thread is solved.

Kortath wrote:I am making my own libs and remove any and all other libs. That switch that I needed allows me to do this very thing.

Kotath, are you sure that the switch in question (-Ofast) prevents (or indeed plays any part in preventing) gcc from using "any and all other libs" ?

If you are not sure then you should not make such statements. Others may in future rely on your information.

Are you sure that it is the cross-compiler that adds large libraries to your kernel? I seriously doubt it. You may want to consider compiling with -Os to minimize the size of the kernel if that matters. Also, 1 MiB is not an unreasonable kernel size. My money is on you combining COFF and ELF files causing some serious bad voodoo to happen. Also, why don't you just pass -f elf to nasm and just use ELF exlusively? Actually, thinking about it, my bet is that the culprit is that you use "flat executables" which is a pretty stupid format. I bet your kernel image is filled with zero bytes because you didn't link things closely enough.

sortie wrote:Are you sure that it is the cross-compiler that adds large libraries to your kernel? I seriously doubt it. You may want to consider compiling with -Os to minimize the size of the kernel if that matters. Also, 1 MiB is not an unreasonable kernel size.

The -Ofast switch, shrunk my kernel, with all my code, down from over 1 meg to only a few K in size. -Os didn't do anything. It in fact was a useless switch for my needs. According to the GCC Docs the -Ofast switch is the highest optimization you can get. Also, I use -ffreestanding switch with it to remove the standard library. What's the difference you may wonder ? The -ffreestanding switch gets rid of the standard library, but will not get rid of GCC built in code, and -Ofast optimizes the GCC built in code down as far as it can take it. ( About a megs worth. ) Since we are working with the C language, it will not be as tight as assembly language, sure. But I don't want to write my kernel in Assembly, and C works great. So I am sticking with C.

Here is what the Doc says about it :

-Ofast
Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math and the Fortran-specific -fno-protect-parens and -fstack-arrays.

When you follow -O3 back it states that it incorporates all -O2 all the way down the line. The -Ofast switch is the top most optimization you can get with this version of GCC.

As you can also see it turns off a lot of protections. That means I am fully responsible for finding my own errors. Which is what I prefer.

Here is the link if you want to read more about it :
http://gcc.gnu.org/onlinedocs/gcc/Optio ... on-Summary

Here is the optimization section specifically.
http://gcc.gnu.org/onlinedocs/gcc/Optim ... ze-Options

Anyhow, you guys are awesome. I appreciate you making sure I am not going in the wrong direction here. You guys rock.

Hi,

sortie wrote:You may want to consider compiling with -Os

Kortath wrote:It shrunk my kernel, with all my code, down from over 1 meg to only a few K in size. According to the GCC Docs the -Ofast switch is the highest optimization you can get.

There's a misunderstanding here. Optimisation for speed and for size are two completely different things. -Os optimises for size and -Ofast optimises for speed.

Cheers,
Adam