OSDev.org

I'd like to kick those gcc developers in their ... well, where the sun never shines.

Imagine, I'm on the hunt for some very weird, very hard to find bug: you do some common operation (like starting an application from the start menue) - and suddenly, out of nowhere, it crashes at the point where it returns from the relevant system call - in short, the complete stack image of that thread is trashed. The darn thing is, I haven't found out why - I've cleared some other bugs on the way to shoot down this nasty one, but alas, I couldn't track it down - because at work - with gcc 4.0.4 - it works.

On my laptop - with gcc 4.0.7 - it works.

On my main developer machine - with gcc 4.1.2 - it craps out.

The thing is, I can reproduce the bug, but I haven't found a solution for weeks now - except to switch compilers and don't worry anymore about what weird internal stuff that f***ing gcc 4.1.2 is doing to my code - as it looks, the registers get trashed and bashed. Oh, I'm fed up with that crap I canna say.

My current solution is: I have compiled binutils 2.16.1 and gcc 4.0.4 on my main developer machine - in a different directory, which I refer to in my makefiles - and leave the damned gcc 4.1.2 alone for the sake of it.

Oh, I hate it ...

Sometimes i'd wish for the toolchain to be more thoroughly tested than this. Instead we can only tell other people not to use Version X. But apparently that's what you get for open source software.

Which is why my default gcc is still 3.4.4

(for the same stupidity, my os breaks on a parser bug in the 2.16 series of binutils)

Does it happen when calling C code from assembly code? If so the version specific issues might be related to the C functions trashing certain registers. Try to narrow down which registers are being trashed in the (gcc version FUBAR) and which ones are not being shredded in (gcc hooray).

i don't think the gcc devs bother if gcc can compile operating systems fine because most programmers don't program operating systems. They are probably fine if it can compiler the popular open source kernels like linux and the bsds.

GCC is very well-tested. However, bugs happen.

I would first double-check the bug is to blame on GCC (and not, say, the version of the clib). Then I'd try to diff the object files, to track down where GCC 4.1.x generates code differently. Then I'd file an official bug report, after checking that the code construct generating different code is actually valid, and not making use of some "undefined behaviour".

As far as I can tell, the GCC maintainers do bother when their compiler breaks valid code, OS / kernel space or not.

I agree with Solar, GCC is very well maintained. I can ensure you commercial compilers do not achieve the same quality...

I think your problem is probably a side effect of something you do not control. Look at the diff of the generated assembly files.

Oh, something which isn't controlled?

Sure, it must be in the depths of my task switcher ... then tell me: I click the Icon - the program starts up. I click the button in the Menue - I get a paging exception and the program gets killed. Now, this doesn't happen with the gcc 4.0.X line, I have experienced.

@Solar: Yes, diff is a fine tool: I've found quite a lot of differences - the more, gcc 4.1.2 produces way bigger binaries than gcc 4.0.4 - I'm rather baffled about this. But the one very crucial function (syscall - inline assembly) looks exactly the same when produced with the two of them.

So it IS possible, that my task switcher has some problem.

Despite this, I'm quite fed up with gcc developers ... imagine you've got something working for ... months if not years and suddenly it craps out because you've switched compilers ??!!

ah, end of rant.

I'll go through my kernel code once again and take a look at it.

Stay safe

ineo wrote:I can ensure you commercial compilers do not achieve the same quality...

I beg to differ. GCC is a fine tool, and no other compiler I know has its versatility, but there are others out there that beat it hands-down in compliance (EDG / Cameau) or quality of generated code (ICC).

distantvoices wrote:Despite this, I'm quite fed up with gcc developers ... imagine you've got something working for ... months if not years and suddenly it craps out because you've switched compilers ??!!

Happens all the time, because it is rather easy to leave the path of strict standard compliance and depending - unwittingly - on something that is implementation-defined or undefined.

The problem is, as much as you might curse the compiler update, in such a case only your source is to blame... (*)

*: Right now I am working on this very problem here in office... our code used to be dual Solaris / Windows, just no-one checked the Windows compatibility for some time. You wouldn't believe what bogus code the Solaris compiler accepted without raising a fuss. Not just "fuzzy" code, either, but downright broken stuff. And I am sure, had we developed under MSVC, we would have the very same problem the other way round.

Have you tried running GCC in the strictest possible error checking mode? I don't mean -Wall -Wextra, I mean the whole shebang available from the manuals. You will most likely get a huge list of false positives, but there might be your bug right among them...

Solar wrote:

ineo wrote:I can ensure you commercial compilers do not achieve the same quality...

I beg to differ. GCC is a fine tool, and no other compiler I know has its versatility, but there are others out there that beat it hands-down in compliance (EDG / Cameau) or quality of generated code (ICC).

I agree with Solar. As much as open source can accomplish, hiring the same people and a few more and paying them money to do their hobby gives better results since they don't have to worry about making money beside it.

Happens all the time, because it is rather easy to leave the path of strict standard compliance and depending - unwittingly - on something that is implementation-defined or undefined.

The problem is, as much as you might curse the compiler update, in such a case only your source is to blame... (*)

Have you tried running GCC in the strictest possible error checking mode? I don't mean -Wall -Wextra, I mean the whole shebang available from the manuals. You will most likely get a huge list of false positives, but there might be your bug right among them...

Tell that to your colleagues who insist that warnings are just a nuisance and that half the warnings can be kept unfixed since they're not a problem.

On the other hand, they're the same folks that insist that virtual destructors clutter an interface and thereby make controller classes that use a huge switch on an encoded type enum with an equally unmaintainable static_cast + delete.