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."
How can BSD be dying when it has a mascot like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!
You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl! Doesn't she make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little cock teaser. Even this old bearded Unix guru is apparently unable to take his eyes off her!
With sexy chicks like the lovely Ceren you will have people queuing up to buy open source products. Look! This guy can't get in there fast enough with her in the doorway! Come on, you must admit she is better than an overweight penguin! Don't you wish you could get one of these? Join the campaign for more cute open source babes today!
if an optimization would break gcc's portability model they could just fork.
...
Surely you forgot the "off"
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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?
I love and trust OpenBSD, I really do. Nothing is more secure for a firewall or external server. But if they're not going to use the maintained versions of programs, I have little sympathy for their troubles; these situations have a big "for masochistic hobbyists only" sign all over them.
This is where I stopped reading. This has been "fixed" for a long, long time. If the GCC port is too old and has gone unmaintained, then just maybe it's time to throw it out and start over. The 2.x compiler is dead and buried. Nobody's interested in maintaining it. Patches for it are not going to be accepted.
For those interested in why certain kernel code has to be inlined (under any kernel): early in the boot process, you can't necessarily call functions. There's not enough of a sane stack or relocatable memory. Linux got bitten by this many times, relying on undefined behavior in particular versions of GCC. The choices are either to write one long hairy function, or force inlining.
GCC introduced always_inline for just those situations. Of course, if the users are still trying to get 2.x from years back to work, they won't be able to use it...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
So why is it Apple can't make a real processor-specific-optimized version of GCC for Mac OS X?
There is no advantage to deviating away from GCC too much because you miss important optimizations in the main GCC trunk. BTW, Apple does have its own GCC tree fine-tuned for Mac OS X - they'd virtually have to as an OS vendor (think device drivers written in GCC 2.95 versus GCC 3.2). Apple would love to merge it back into the GCC main (complete with Objective C++), but the GCC project only accepts very conservative patches generally.
A while back, when I was hacking a new option into the Objective-C compiler (for 2.9.5), I ran into an interesting duality in GCC. Some things are really easy to change, others considerably less so.
The back-end of GCC is pretty cleanly designed, so it's not too hard to change the object code output for a particular processor, or even to add support for a new processor (as long as it's a 32-bit, RISC processor with lots of general purpose registers).
On the other hand, the front end is a mess. Heaven help you if you want to change the parser behavior. Even something as basic as the processing of command-line options is needlessly complicated. The GCC driver program and the C frontend use entirely different code for processing the command line.
Changing the output of the compiler was actually easier than getting the options passed from GCC into the Obj-C frontend so I could actually turn the new behavior on and off.
I even found out that there were several options in our version of GCC that didn't do ANYTHING, since they never actually got passed down to the compiler from the GCC driver.
Someday, I may get motivated to sit down and make a real effort to fix this mess. I wonder if anyone would care?
-Mark
" and proves that diving into gcc is not as hard as one could imagine."
Yeah, right. I'll continue the designs of my thermonuclear weapon using that abacus that I have lying around here.
Moomin
I can make a dead gcc with zero knowledge of C.
"I think this line is mostly filler"
don't take the following out of context:
"Notice how CUM, the first parameter, is used unprotected? Guess what happens in the CUM++; statement when CUM happens..."
oh, you filthy little bastards...
Wow, that looks pretty simple... BrainFuck back-end here I come!
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.
And that's why the front end was reworked for the GCC 3.x.x compilers. Supposedly they are much cleaner, and tasks like tracking the newest features of standards are easier now.
If tits were wings it'd be flying around.
ROTFLMAO!!! Thanks for making me smile!
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
Let's make sure that no one ports anything to the next generation of CPUs from Intel or AMD so I can learn GCC too!!
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.
><));>