GCC 3.3.x and GCC 2.95

[amirsadig]

I use VMWare, it let make use different OS (also in Graphic Modes).
as I mentioned in another Thread "Hardware task switching" I have a problem with Task Switching. as problem appear I use GCC 3.3.1 in SUSE 9.0.

now I have tried my old lovely Linux OS (Debian sarge). it give me the ability to use gcc-2.95 or gcc-3.3.x. and I have compiled the same code ( my old OS backup, which l remember it work).

with gcc-3.3.x I have GPF (exception), but when I use the gcc-2.95 (which I have used before as write my OS) it work as I expected.

is there difference when using gcc-2.95 or 3.3.x? should I notice some roles during OS development?

here is the gcc flags which I use to compile the code:

-D__KERNEL__ -g -Wall -W -O2 -nostdinc -fno-builtin -I$(INCDIR)

[Solar]

There is a world of difference between GCC 2.9x and GCC 3.x, as the bump in the major version number might indicate. The C++ ABI changed for sure, and many other details likely changed too. (The optimization, for example, is very likely to be different.)

Probably your best bet is to dump disassembled output of the 2.9x and the 3.x compile to file and diff that to see what turned out different.

[amirsadig]

I have make what you have said. but it alot off differences between the two files and I am not good assembly programmer so that I can see why the two kernel executed themself differency!

as I looked in Internet (the Linux kernel recommend gcc-2.95 version) because it more stable than gcc-3.3) but some in the future I must use the newest GCC version.

[Solar]

I fear there's little you can do except for porting every single module of your kernel. If you don't have unit tests set up that show you any regressions in your code, that can turn out to be some serious pain...

[Candy]

I have make what you have said. but it alot off differences between the two files and I am not good assembly programmer so that I can see why the two kernel executed themself differency!

I am using 3.3.2 (and 3.4.0) for my OS and it didn't turn up any problems. Do you compile with -Wall and -W? If not, does it turn up any warnings when you do?

[Solar]

@ Candy:

Yes, he's using -Wall -W as he pointed out in his first posting. Oh, and it's -Wextra instead of -W today.

No, I don't think he wrote any wrong code. But chances are good he wrote implementation defined code, which is legal but likely to break between compiler versions. __packed__, for example, is implementation defined...

[amirsadig]

@ solar
what did you mean with implementation defined code

as I said in the linux 2.6.6 docs, they said they recommended gcc-2.95.x x>3. with gcc-3.3 will not work correctly as they expect. they must fix something the kernel so that it could be work good with gcc-2.95.

[Pype.Clicker]

if i were you, i would check that:
- your preciousss structures (descriptor tables entries, etc) still have the correct size
- registers you assume to be preserved by the caller/callee are same as those the compiler assume to be preserved by caller/callee ...
- you didn't do anything weirdo like 0-length arrays, etc. using -ansi may help locating such 'weird things'. Then check `info gcc` to see if anything has changed...

[Solar]

@ solar
what did you mean with implementation defined code

When you write code, that code can be several things.

It can be Standard-Correct - written by the book, and any compiler that is not broken itself should translate it correctly. GCC 2.95 or 3.3.1 or whatever, it should not matter. Your code GPF's when compiled with GCC 3.3.x, so it's not Standard-Correct - but actually very few non-trivial programs in this world are.

It can be broken - no compiler should accept such code without spitting errors at you. The fact that your code was accepted by GCC 2.95 and didn't produce errors under GCC 3.3.1 shows it's not broken either.

So you are left with two options. Your code might produce undefined behaviour - like, using a variable without initializing it. The results are just that, undefined. This run it might work, next run it might break, and no-one is obliged to tell you why. "Undefined" is a synonym for "broken, but the compiler need not tell you about it". That's why you should always use -Wall -Wextra, since that tells the compiler to warn you about as many cases of undefined behaviour as it can identify.

But you use those two options, as you said above, and that's why I suspect you have code that results in implementation defined behaviour. Some things the C/C++ standards committee left to the compiler builders. They are allowed to do things this or that way, and to change this behaviour between compiler versions. How the compiler aligns strctures, for example, or in which order the parameters of a function call are evaluated. That's the stuff that might have changed between 2.95 and 3.3.1, and the only way to find out is to study the change logs between the versions, and to re-test your code to find out where you've been relying on some special feature (bug?) in 2.95 that's no longer there in 3.3.1.