MINGW with certain flags / MSVC crashes my kernel

[lakuj]

Hello

I read all the info in the OSFAQ on MINGW/MSVC/CYGWIN etc but I still have some weird problems, recently I've switched to MINGW from DJGPP, the switch went pretty smooth with small adjustments to now compile and stip the PE format and everything works.

Since my primary development environment is MSDEV I figured that if I can make the kernel from the PE file I could use MS visual studio 2003 to compile it.
After spending several hours fixing all the things MS compiler didn't like about C conformence, compiler specific quirks such as __inline __asm and __attribute__, it worked.
However, it worked on a very minimal configuration that I've set up just to test if it works, when I added other things like user processes it just crashed, I used to get bad variables when returning from processes/threads etc - while mingw/djgpp worked.

I then gave up for now, and tried to learn a little bit about GCC optimization flags, the current flags that I use are:
@Gcc -masm=intel -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin.

Which is just a simple non optimized version, which 100% works.
I then added -O1, and voila! it crashed!
I looked into GCC documents and saw that:
`-O' turns on the following optimization flags:
-fdefer-pop
-fmerge-constants
-fthread-jumps
-floop-optimize
-fif-conversion
-fif-conversion2
-fdelayed-branch
-fguess-branch-probability
-fcprop-registers

I then added all the flags manually into my compile line, removed the -O1, it now should be identical right? wrong!
The kernel worked. I then looked at the .S output of both versions and had found out what was obvious, the code was completly different!

Does -O1 turns other things that I am not aware about?
If I want to find out what crashes it I need to pinpoint what specific optimization generates code that fails, does any one know what -O1 adds except what the documentation writes about? I want to be able to manually write all the flags so I can remove one by one to check what crashes and fix my kernel accordinly.
This though has nothing to do with inlining as I looked at the .S source and in both versions what shouldn't be inlined does not get inlined.

I know this is just a "semi" OS questions but it regards strictly to OS so please bare with me, if anyone has any ideas on MSVC I would be most pleased to know as well.

Thanks!

[Solar]

I looked into GCC documents and saw that:
`-O' turns on the following optimization flags:
-fdefer-pop
-fmerge-constants
-fthread-jumps
-floop-optimize
-fif-conversion
-fif-conversion2
-fdelayed-branch
-fguess-branch-probability
-fcprop-registers

Double-check that the docs refer to the specific version of GCC you're using. Especially the optimization settings changed quite some throughout the 2.x -> 3.x -> 4.x major releases.

[lakuj]

The document that I was reading (gcc.info) came with the MINGW installation and correspond to the GCC version 3.4.2 that I'm using.

Any ideas?

[Pype.Clicker]

i'd be tempted to say that you might miss some important information about "register spilled" by some asm command. E.g. if you don't tell gcc 'asm("rep movsb")' can modify the %ecx register, then it will assume its content is kept.

This has quite little implications in non-optimized code (which will probably never try to keep a value in a register between two instructions), but it can be very different on -O1, -O2, etc.

[lakuj]

That's ok by me, if I can find what flag causes the compiler to generate such code.

But why does -O1 and the flags the correspond to the -O1 stated by the documents generate different code? what else does -O1 do?

[proxy]

Here's a good way to know what your compiler is throwing at a source file:

Code: Select all

touch blah.c
gcc -v -Q -O1 blah.c

example output:

Code: Select all

$ gcc -v -Q -O1 blah.c
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/specs
Configured with: /var/tmp/portage/gcc-3.3.5.20050130-r1/work/gcc-3.3.5/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5-20050130 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5-20050130/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5-20050130/info --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3 --host=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)
 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/cc1 -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5 blah.c -dumpbase blah.c -auxbase blah -O1 -version -o /tmp/ccqkKwNc.s
GNU C version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1) (i686-pc-linux-gnu)
        compiled by GNU C version 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed:  -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5
 -auxbase -O1
options enabled:  -fdefer-pop -fthread-jumps -fpeephole -ffunction-cse
 -fkeep-static-consts -fpcc-struct-return -fgcse-lm -fgcse-sm
 -floop-optimize -fcrossjumping -fif-conversion -fif-conversion2
 -fsched-interblock -fsched-spec -fbranch-count-reg -fcprop-registers
 -fcommon -fgnu-linker -fargument-alias -fmerge-constants
 -fzero-initialized-in-bss -fident -fguess-branch-probability -fmath-errno
 -ftrapping-math -m80387 -mhard-float -mno-soft-float -mieee-fp
 -mfp-ret-in-387 -maccumulate-outgoing-args -mcpu=pentiumpro -march=i386
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include
 /usr/include
End of search list.

Execution times (seconds)
 TOTAL                 :   0.00             0.00             0.00
 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o /tmp/ccwRsIcg.o /tmp/ccqkKwNc.s
GNU assembler version 2.15.92.0.2 (i686-pc-linux-gnu) using BFD version 2.15.92.0.2 20040927
 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../crt1.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../crti.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../.. /tmp/ccwRsIcg.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/crtend.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../crtn.o
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../crt1.o(.text+0x18): In function `_start':
: undefined reference to `main'
collect2: ld returned 1 exit status

look carefull at the "options enabled" section of the output and you'll know for sure what is enabled.

proxy

PS: here is a site that expains the optimizations in gcc:

http://www.freehackers.org/gentoo/gccflags/faq.html

I would however, focus less on the optimizations as the cause of your problem and more on incorrect code being the cause. There are plenty of constructs you can make in c/c++ which are technically valid but have undefined/incorrect behavior (such as type punning pointers, modifying variables more than once per sequence point, etc...

[lakuj]

Thanks all I figured it out,
it seems that GCC ignores all the optimizations flags unless a -O[123] is used. The default is -O0.
With -O0 (the default) it simply ignores all the optimization flags, as it seems.

[lakuj]

By the way, if anyone wants to know what was the problem:
I didn't save callee-saved registers (ebx,ebp,esi,edi) across synchronization calls (such as Sleep/Mutex etc) which made both mingw and MSVC optimized code to fail.

This is often looked over, as in my case I didn't see it mentioned in a lot of places and just occasionaly saw it in Christopher Giese site (http://my.execpc.com/~geezer/index.htm).

I have verified that MSVC uses the same callee saved registers.

Now the kernel works with both compilers.

[DruG5t0r3]

I had this sort of same issue with my kernel.

When I switched from gcc 3.x to 4.x . The code compiled just fine, but at runtime, everything was just f****d up...

So I had to turn down -O3 to -O0 . Even -O1 doesn't work now. Doesn't really matter anyway. But It almost made me slam my forhead on my keyboard ;D