Slashdot Mirror
Diving Into GCC: OpenBSD and m88k
BSD Forums writes "This OnLamp article by Miod Vallat describes how the m88k-specific backend of the GNU C compiler, gcc, was fixed, from the discovery and analysis of the problems to the real fixing work. Since it started with almost zero gcc internals knowledge, it should be understandable by anyone able to read C code, and proves that diving into gcc is not as hard as one could imagine."
if not for the dead cpu, and the fact that gcc didn't work correctly, what motivation would they have had to do anymore more than a mild glance into gcc?
it was because the cpu was dead, and things didn't work that the attempt was made, and hence the knowledge learned and passed on.
These should be weekly /. regular-type posts. It's always cool to see someone's thoughts and methods for debugging some of the major tools/libraries that we use pretty regularly. Heck, this might even help someone find that obscure Athlon64 problem (not that one exists, just hypothetical). Remember, dead ARCH doesn't mean anything. The methodology of debugging here would work for any ARCH.
Heck, even finding one of those bugs where you compile for i386 and it works, but compiling for i586 or i686 and it breaking would be kinda cool. I just learned a few things about GCC's build that I didn't know. New info for the day! Huzzah!
-What have you contributed lately?
If I recall correctly, gcc3 "fixed" the m88k backend by deleting it, because it was unmaintained. So it's no surprise that this hobbyist has to use gcc2; if it makes him happy, there's no need to be so enthusiastic about explaining that gcc2 is dead -- and no need to use subjects like "Oh, catch the hell up."
He was working on this because it's dead. That's why there were problems that needed to be fixed. He wrote this up because he's a nice guy, and he wanted to let others benefit from his effort.
This is important (as in ``stuff that matters''), because it gives a clue about some general methods for troubleshooting a compiler. If you're looking for a Howto that's specific to your particular architecture/compiler problem, you may have a long wait.
Even though this shows a good starting point at jumping into GCC and ARCH debugging, it completely alienates all the Slashdot readers who don't have a rather high level understanding of how compilers work and the debugging process in general. The author presents a very readable and complete overview of the process he used, which is good. Unfortunately, he doesn't go into any details of why he chose to do what he is doing or the effects of doing it a different way.
This article is only truly accessable to the readers who are already familiar with C and wish to spend at least an hour going over the article and accompanying code. Even then, looking from the comments posted thus far, most readers will still be unable to grasp what is truly going on in the author's head or in the process he uses.
This article does belong in slashdot, but not the front page.
><));>
gcc is one of the reasons a number of developers in *bsd land are waiting for this to mature. others (theo is a big advocate) are trying to get the plan9 toolchain freed up more.
and then there will truly be a *free* operating system.
vodka, straight up, thank you!