Diving Into GCC: OpenBSD and m88k 167
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."
OpenBSD and sexy women (Score:2, Funny)
You just can't take Linux [redhat.com] seriously when its fronted by losers [nylug.org] like these. You Linux groupies need to find some sexy girls like her [hope-2000.org]! I mean just look at this girl [madchat.org]! Doesn't she [madchat.org] make you hard? I know this little hottie [madchat.org] floats my boat! This guy looks like he is about to cream his pants standing next to such a fox [spilth.org]. As you can s
Re:OpenBSD and sexy women (Score:3, Funny)
Re:OpenBSD and sexy women (Score:1)
OpenBSD and m88k (Score:1, Funny)
Re:OpenBSD and m88k (Score:5, Insightful)
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.
Re:OpenBSD and m88k (Score:2)
They won't get any help from anywhere else.
Everything to gain, nothing to lose.
This is a different world. It has almost nothing in common with normal development.
The critical information is that is wasn't as hard as one might expect.
Since this is dead-end anyway, it does not matter what side-issues you wreck.
This does give anecdotal evidence of the value of Open Source for legacy enterprise applications. Old unsupported softw
Re:OpenBSD and m88k (Score:2, Funny)
I'm doing the same on Xenix (Score:2)
Re:OpenBSD and m88k (Score:2, Insightful)
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
Re:OpenBSD and m88k (Score:1)
From the better late then never department. (Score:1)
Protection (Score:4, Funny)
Re:Protection (Score:1, Funny)
why i use openbsd (Score:1, Funny)
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 lapto
Re:Mod parent TROLL (Score:1, Offtopic)
Cool (Score:4, Insightful)
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!
Oh, catch the hell up. (Score:5, Informative)
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...
Re:Oh, catch the hell up. (Score:5, Insightful)
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."
Re:Oh, catch the hell up. (Score:3, Insightful)
and then there will truly be a *free* operating system.
Re:Oh, catch the hell up. (Score:2)
And it's the *BSD people who frequently accuse the GNU people of obsessive zealotry, but it's really the same thing on your side of the fence too.
Re:Oh, catch the hell up. (Score:2)
FYI, this came up on deadly.org a while back and it was pretty clear that a non-gcc compiler is not a priority for most (any?) of the main OpenBSD people. If someday one works as well as gcc, great, but it's not going to happen any time soon.
Re:Oh, catch the hell up. (Score:2)
Pure FUD, plain and simple (Score:2)
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 -- a
Re:Pure FUD, plain and simple (Score:1)
You do realise you're replying to an AC, right?
Re:Pure FUD, plain and simple (Score:2)
Yeah, but he's just the one who happened to speak first. There are others who spout the same monkeypoo, and I'd've replied to them as well.
I've come to view slashdot as the equivalent of those black-and-white 16-page "newsletters" that sit by the checkout queue at the grocery stores. Pure speculation, loud and ignorant rhetoric, and lots of sensationalism. Anything to get the traffic increased and the banner-ad hit rate up. Everyone's always known that the journalistic integrity and skills of the edit
CodeSourcery, Apple (Score:2)
Cygnus *used* to be the dominating GCC contributor, with about half all patches. However, that was before the eg
Re:Oh, catch the hell up. (Score:2)
Perhaps my tone came across harsher than it was meant. If someone wants to burn hours on a dead-end street, hey, whatever floats his boat.
Or, he could start with current development sources, do the m88k back-end from scratch like I suggested, and then not only would the port be alive again for others to use, he would have the help of all the current maintainers. Everybody wins.
Shoot, the 2.x m88k code probably wouldn't need that many changes to be brought into line with the rest of 3.[34]; he could e
Re:Oh, catch the hell up. (Score:2)
Re:Oh, catch the hell up. (Score:2)
Re:Oh, catch the hell up. (Score:2)
In both cases, you have to run with what you've got. In both cases, you can't get any help. You can't even get any sympathy.
You fix one thing that's vital and maybe break half a dozen things you neither know nor care about. This is where the value of Open Source really lies.
My experience: some things easy, some less so... (Score:5, Interesting)
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
Re:My experience: some things easy, some less so.. (Score:2, Interesting)
Re:My experience: shooting from the hip (Score:2)
Who knows, but I
GCC: "not as hard as one could imagine" (Score:2, Funny)
Yeah, right. I'll continue the designs of my thermonuclear weapon using that abacus that I have lying around here.
Moomin
whatever you do (Score:2, Funny)
"Notice how CUM, the first parameter, is used unprotected? Guess what happens in the CUM++; statement when CUM happens..."
oh, you filthy little bastards...
Easy! (Score:2)
Re:Easy! (Score:2)
You have no idea how tempted I've been to do exactly that.
Another example of strange compiler problems (Score:1)
Re:Another example of strange compiler problems (Score:1)
Hey.. you're right! (Score:2)
Inaccessable (Score:2, Insightful)
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
Re:Inaccessable (Score:2)
Erm, what's the point of diving into gcc if you're not familiar with C? That's like an illiterate trying to read a book about bookmaking.
Re:Inaccessable (Score:5, Insightful)
This article does belong in slashdot, but not the front page.
Wow. I was overjoyed that SlashDot had finally posted something of technical interest and not another junk piece about how the RIAA are coming to get the freedom loving song-swappers.
Don't worry, the drivel that you are used to will be back sooner than you can blink.
Re:Inaccessable (Score:2)
If only you were right - a good many of us would be thrilled if Slashdot readers who don't have a high level understanding of "how compilers work and the debugging process in general" were completely alienated.
*dang* your UID is showing (Score:2)
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
Misdirected anger (Score:1)
[I am a subject] (Score:1)
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 [dragonflybsd.org] only start development
"...not as hard as one could imagine...." (Score:2)
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.
Esay? (Score:2)
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 g
Re:Esay? (Score:2)
angel'o'sphere
Re:Esay? (Score:2)
You dont take a course in german either, do you?
angl'o'sphere
Re:Esay? (Score:2)
Also: you can give me a malus in browsing, so you don't see my posts. Just in case my typos hurt your eyes.
angel'o'sphere
Re:hard (Score:4, Funny)
Surely you forgot the "off"
Re:hard (Score:5, Informative)
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.
Re:hard (Score:2)
>>>>>>>>>>>>&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++.
Re:hard (Score:2)
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-st
There is a objc-improvements GCC branch (Score:2)
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 A
Re:Hey, it wouldn't be a party without me! (Score:1)
Re:Who the fuck modded this informative? (Score:1)
Re:My experience (Score:2)
Re:My experience (Score:2)
Satire? Seems more like slapstick to me
Re:My experience (Score:2)