[ Solved ] Windows 7 x64 ( Cross Compiler ) NO Libs

[Kortath]

Hi,

You may want to consider compiling with -Os

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 optomises for size and -Ofast optimises for speed.

Cheers,
Adam

Ahh you ninja'd me.. lol

I updated my comment above.

[dozniak]

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.

A corollary here: -Ofast will most probably make your code bigger, not smaller.

[Kortath]

A corollary here: -Ofast will most probably make your code bigger, not smaller.

Well you have your theory, because I got the total opposite when I actually did it. It made my file size smaller. As I stated in my previous posts, it went from a meg down to a few k in size.

[sortie]

It has not crossed your mind that -Ofast just happens to enable some optimization that has a side effect of suppressing the real problem? Perhaps it makes the sections just the right size such that the conversion to flat binary doesn't contain a lot of zeroes? If you don't understand *why* -Ofast makes your kernel very significantly smaller, when it'll usually will make larger, then it'll break one day and you'll be back where you started.

[Kortath]

It has not crossed your mind that -Ofast just happens to enable some optimization that has a side effect of suppressing the real problem? Perhaps it makes the sections just the right size such that the conversion to flat binary doesn't contain a lot of zeroes? If you don't understand *why* -Ofast makes your kernel very significantly smaller, when it'll usually will make larger, then it'll break one day and you'll be back where you started.

OK your comments make a lot sense. But what I am not seeing is a bloated ( lot of zeros ) file. Granted, I now understand where your coming from, but my os wouldn't boot into the kernel until AFTER I did the -Ofast command. It worked as it should. I have even tweaked a few things here and there and it still works as long as the -Ofast switch is in place. I even compared my compiled code on the windows 7 32Bit using djgpp. It does a similar thing, with little zeros as bloat. So I can only comment on what I have physically been seeing all along.

[Combuster]

It has not crossed your mind that -Ofast just happens to enable some optimization that has a side effect of suppressing the real problem?

The behaviour is undefined, so doing nothing is a correct interpretation?


My crystal ball is saying you should fix your linker script.

[Kortath]

It has not crossed your mind that -Ofast just happens to enable some optimization that has a side effect of suppressing the real problem?

The behaviour is undefined, so doing nothing is a correct interpretation?


My crystal ball is saying you should fix your linker script.

Yes my linker script is custom made. It's why I am grateful that switch was available.

Linker.ld

Code: Select all

OUTPUT_FORMAT("binary")

SECTIONS
{
  .text 0x100000 :
  {
      code = .;
      _code = .;
      __code = .;
      *(.text)
      *(.rodata*) /* <---- ELF Cross Compiler or ELF *NIX (eg. Linux) */
      . = ALIGN(4096);
  }
  .data :
  {
      data = .;
      _data = .;
      __data = .;
     *(.data)
     . = ALIGN(4096);
  }
  .bss :
  {
     bss = .;
     _bss = .;
     __bss = .;
     *(.bss)
     . = ALIGN(4096);
  }
  end = .;
  _end = .;
  __end = .;
}

[gerryg400]

Kortath, it is quite common here on this list (it's been discussed before) and where I work to specify that tests be done at various levels of optimisation to ensure that optimisation options are not having an effect on the operation of code.

Sometimes this is done as a side effect of the fact that debugging is done at one optimisation level and real operation at another.

Generally, if a test fails at any optimisation level it is considered to have failed and there is absolutely no way that the QA team would accept that "-Ofast" fixes something.

Please, for your own sake, remove the -Ofast option and find out what the problem was and fix it correctly.

[Kortath]

Kortath, it is quite common here on this list (it's been discussed before) and where I work to specify that tests be done at various levels of optimisation to ensure that optimisation options are not having an effect on the operation of code.

Sometimes this is done as a side effect of the fact that debugging is done at one optimisation level and real operation at another.

Generally, if a test fails at any optimisation level it is considered to have failed and there is absolutely no way that the QA team would accept that "-Ofast" fixes something.

Please, for your own sake, remove the -Ofast option and find out what the problem was and fix it correctly.

Hmm, OK I'll look into that. The more I dig into this conversation the more I am now understanding why everyone is saying that -Ofast is wrong to use. Thanks for the explanation.

I have been going over all the details of what everyone on this thread has been saying. What bothers me is that the cross compiler might have compiled incorrectly. I'll go back over it and recompile it and see what comes of this.

EDIT UPDATE : Well turns out that GCC Cross Compiler version 4.8.1 ( Latest Version ) has failures all across the optimization switches : -O2 and -O3. No wonder they failed.. Here is just one of several links that I found :

http://gcc.gnu.org/ml/gcc-testresults/2 ... 01612.html

After a lot of searching I found that many many version of GCC has had optimization problems. This is a huge problem and thus makes GCC useless for OS Creation.

Sigh.. back to the drawing board and back on 32-Bit Windows 7 for OS creation. At least DJGPP works. Someone made the comment on another thread wondering why people keep using DJGPP, now I see why.

Might as well lock this thread as I see now why everyone is calling me ignorant since GCC is obviously so useless. I won't bother with GCC any longer. Thanks for the education guys.

[FallenAvatar]

GCC is not the issue. For OS Dev, you will be hard pressed to find a better compiler. The issue is how you are looking at a compiler.

A compiler will do optimizations where it can. (period!) This is part of the job of a modern compiler. The issue you are running into is that you want zero outside dependency, and this is impossible. You are reliant on your current OS (Windows), your current compiler (GCC), your current linker (GCC/Ld), and your hardware. Nothing you do will remove these dependencies, so stop trying. And what I mean by that is that libGCC is a part of GCC. And the compiler using it is to be expected.

YOU need to learn why it needs/relies on it, and how to help YOUR compiler understand what it is supposed to be doing (either by command line switches, or using a correctly --configure'd cross compiler)

Ignoring this issue will simply cause much more complex/hard issues later.

- Monk

PS: DJGPP will cause infinitely more issues later than fixing your understanding of GCC, or more importantly, your tollchain will now.

[gerryg400]

EDIT UPDATE : Well turns out that GCC Cross Compiler version 4.8.1 ( Latest Version ) has failures all across the optimization switches : -O2 and -O3. No wonder they failed.. Here is just one of several links that I found :

http://gcc.gnu.org/ml/gcc-testresults/2 ... 01612.html

After a lot of searching I found that many many version of GCC has had optimization problems. This is a huge problem and thus makes GCC useless for OS Creation.

Sigh.. back to the drawing board and back on 32-Bit Windows 7 for OS creation. At least DJGPP works. Someone made the comment on another thread wondering why people keep using DJGPP, now I see why.

I think that's a poor decision based on hasty research.

There is in fact much evidence indicating that GCC is useful for OS creation. Dozens of hobby OS's and a good number of successful open source and commercial OS's are created using GCC and this alone testifies to its usefulness.

[NickJohnson]

@OP: you also realize that DGJPP is a port of GCC, right?

Also, that page you found shows GCC optimizations breaking some code, but doesn't imply that that code was properly written. I've had plenty of cases where optimization flags triggered or hid bugs, but it was always because I was accidentally producing undefined behavior. I have heard rumors of -O3 breaking correct code, but never any hard evidence. My entire Linux system is compiled with -O3 and I don't have any problems. Optimizations don't break correct code, and if they do, they don't break good code.

[dozniak]

@OP: you also realize that DGJPP is a port of GCC, right?

An unsupported, underperforming, outdated port I must add.

heard rumors of -O3 breaking correct code, but never any hard evidence. My entire Linux system is compiled with -O3 and I don't have any problems.

-Ofast and specifically -ffast-math may cause some "unexpected results" by stepping away from strict IEEE 754 conformance.
Most of the other "optimization bugs" are caused by invalid code you wrote in the first place. Implementation-defined behaviours, undefined behaviour, simply doing things that are far out. C is very powerful language and it will allow you to do incredible things, far outperforming anything that more "hand-holding" languages could do. But it comes with a price.

TL;DR: Fix your code first, don't blame compiler tested by decades of thousands other peoples' developments.

[Owen]

@OP: you also realize that DGJPP is a port of GCC, right?

An unsupported, underperforming, outdated port I must add.

As much as I emphasize using an actual cross compiler, I also emphasize the truth.

DJGPP is currently built in GCC 4.7.3 and Binutils 2.22. I wouldn't exactly call that old.

heard rumors of -O3 breaking correct code, but never any hard evidence. My entire Linux system is compiled with -O3 and I don't have any problems.

-Ofast and specifically -ffast-math may cause some "unexpected results" by stepping away from strict IEEE 754 conformance.
Most of the other "optimization bugs" are caused by invalid code you wrote in the first place. Implementation-defined behaviours, undefined behaviour, simply doing things that are far out. C is very powerful language and it will allow you to do incredible things, far outperforming anything that more "hand-holding" languages could do. But it comes with a price.

TL;DR: Fix your code first, don't blame compiler tested by decades of thousands other peoples' developments.

There are occasional bugs at -O3 (more often than -O2 or -Os), but they are rare.

That said, compiling an entire system at -O3 is a great way of making it slow. O3 is a harsh optimization mode: it can really enlarge your code; applied outside of tight loops, it tends to pollute the instruction cache and make things slower.

I recommend -Os for most things.

I also recommend that the original poster fix their linker script. They could perhaps start by putting the COMMON section somewhere. Not doing things like that is an excellent source of gigantic binaries.

[dozniak]

DJGPP is currently built in GCC 4.7.3 and Binutils 2.22. I wouldn't exactly call that old.

Well, reasonable, I don't watch it too closely.

I recommend -Os for most things.

Also reasonable, for kernel there's usually much more benefit in not wasting too much caches and best not evict other apps code and data while running the kernel, -Os fits.