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!
I know it's an example of how to start messing with gcc, but perhaps it would have been better not to use a dead CPU and a dead OS to make the point?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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
Now that the M88K is extinct, we have gcc 2.95 support for it ;) ... now where did I put that VME box...
Maybe the rain Isn't really to blame. So I'll remove the cause, But not the symptom!
I use openbsd because its hack-proof. They have the security team that every software company wants. i have been using openbsd since version 2.3 and no one has hacked my laptop yet. i feel very safe and secure using this operating system.
m88k processor? is that better than intel p4? If so, how do i upgrade my dell laptop?
The reason i ask is cause i want to be on the leading edge of technology. i dont want to be insecure either. thats why i use openbsd. because i have not been hacked yet on my laptop. its a nice thought to know that no one has accessed my machine from the outside.
i think every machine should run openbsd.
just my $0.02
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
Nothing better than working on MS Unix!
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!
Since Apple's device drivers don't use C++,
>>>>>>>>>>>>&g t;
All device drivers that use the I/O kit (that is, most of them) are written in C++, because the I/O kit is C++.
A deep unwavering belief is a sure sign you're missing something...
A couple of years ago, I was trying to write my own little stack-oriented language. I had written an interpreter for it in Turbo Pascal 3.0, an extremely old Pascal compiler. There was some kind of problem with the program, and when I was trying to find the cause, I discovered that just declaring a new variable (without ever using it) solved the problem...
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.
><));>
Who knows, but I am sure there is someone who still needs those wierd flags, even if they don't do anything anymore.
No.
Christ, folks, if I didn't know better, I'd say you hate *BSD more than you hate SCO.
the GCC project only accepts very conservative patches generally.
This is probably a good thing for such a crucial project by and large, but it does give rise to frustration among developers (and, historically, the whole egcs and pgcc malarkeys). Perhaps they should make a permanent gcc-unstable branch, to serve the same purpose that egcs did but not just on a temporary basis. That way "risky" patches such as any Apple might submit could go into the unstable tree and gradually find their way into gcc-stable.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Now, I realize that *BSD is growing less and less popular, but I truly must say that it has always impressed me as being a good system.
I adminster a handful of OpenBSD servers, and they really are a joy to work on; they give me far fewer headaches than any of the Linux distros our clients use. Sure, there are things that frustrate me (especially lack of SMP), but for mission critial applications, I rarely use anything other than OpenBSD.
Also, if *BSD is dying, why did DragonflyBSD only start development back in June?
Maybe I'm an optimist, but I like something to actually work when I need it. (Maybe that explains why I drive a '91 Volvo station wagon)
WTF???
It was EXACTLY as hard as I imagined. It's a good article,and I'm glad it was put up... but the editors need to have a reality check before putting in statements like that.
I thought this was a troll, but it's WAY too over the top for trolling. This is satire, and it's pretty good.
:)
Satire? Seems more like slapstick to me
I cannot find a single true statement in your post other than the fact that the FSF holds the copyright to GCC. (Why you think that makes a difference escapes me.)
There are many other significant developers other than Red Hat employees. Only a quarter of the current list of maintainers are RH employees. Only a third of the steering committee are RH employees. The last time a RH employee was a release manager was back in the 2.x days, and that person worked for Cygnus.
There have been suggestions -- all rejected -- made to the developers to turn GCC into a more Linux-specific compiler. Come to think of it, those have all been made by VA Linux employees, so if you want ridiculous karma-whoring conspiracy theories, you know where to look for them.
All three of the *BSDs have maintainers which regularly contribute time and patches and computing resources to GCC. None of them have ever needed Red Hat's help to do so.
Perhaps you're (badly, woefully, insanely) confused by the fact that gcc.gnu.org is hosted on a Red Hat network. Believe me, it causes them no end of grief for maintenence. And yet you've never seen a "please click the paypal link to keep this server running" there. This being slashdot, I'm sure there are all kinds of useful suggestions about where else such a machine could be hosted, for free, on a high-speed connection, complete with very talented sysadmins. Anyone? Anyone? No? No.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Both of the above are probably as significant contributers to GCC as Red Hat. The current release manager is from CodeSourcery, and the big, user visible features in GCC 3.4 are contributed by CodeSourcery (the new C++ Parser) and Apple (pre-compiled headers). And there are a lot of smaller conributors, who combined are more important than any of the big three. This includes the BSD projects.
Cygnus *used* to be the dominating GCC contributor, with about half all patches. However, that was before the egcs fork, which primary purpose was to make it easier for others to contribute. It worked, so while Red Hat now contribute as much as Cygnus used to contribute, other players have entered the game making the playing field more even.
I know that I'm responding to a troll, but someone moderated its lies "interesting", so apparently not everyone has the facts straight.
and Apple is contributing their Obj-C improvements to that branch. There doesn't seem to be any resistance among the main GCC developers to the changes in that branch, but some of the GNUStep people seem less enthusiastic about some of the language changes.
The problem is that the changes in the Apple version of GCC are mixed together and often Apple specific. They need to be seperated, cleaned up, and made generic before inclusion in the main branch. Both Apple and GCC agree that is a good policy, and Apple *is* willing to do the work (because it makes it easier to "track" GCC), and they are doing the work. It just take time.
I do not agree with the poster of the story that "diving into gcc" is far more easy than you might have thought. ... and its likely also far more the avarage Java geek knows about programming.
Indeed the excellent articel shows HOW HARD it in fact is.
You need a lot of knowledge abiout how a compiler works, and how a processor works and how you can write a program to reproduce the bug.
Thats far more the avarage Python geek, PHP geek or Visual Basic freak knows about programming.
Erm
Also: the article does not give a hint how long the timeframe was for that fix.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You're a stupid cocksucker. I think "WOOT" is what people scream when a grizzly bear takes them from behind.
if the article clearly states that *c* is a prerequisite and is about gcc compiler internals on a very specific hardware platform the article is clearly catering for the technical specialist knowlegeable/or interested about such topics. why shouldnt it be on the front page. Since when has the front page been *slashdot for idiots* ?
/. whipper snapper wanting everything NOW ... :)
... hung drawn and quartered before you could even spell slashdot.
...
:)
if you cannot understand *c* or take the time to read and understand the suggested references then do not be surprised the article is unaccessable. Typical young
Dare you *not to do your homework* and post statements like this on the openbsd or gcc usenet forums
RTFM, RTFTB, man gcc(1), read the manual, already faq
Maybe a better suggestion maybe to post a question in the discussion asking for help or for someone to summarize the interesting points. Must use slashdot powers for good, not evil
peterrenshaw ~ Another Scrappy Startup
I don't know whats funnier, this post, or the people who didn't get it and modded down.