Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming GNU is Not Unix Operating Systems IT Technology BSD

Diving Into GCC: OpenBSD and m88k 167

Posted by michael from the swimming-pool-filled-with-double-edged-razor-blades dept.
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."
This discussion has been archived. No new comments can be posted.

Diving Into GCC: OpenBSD and m88k More

Diving Into GCC: OpenBSD and m88k

Comments Filter:

  • OpenBSD and sexy women (Score:2, Funny)

    by Anonymous Coward
    How can BSD [freebsd.org] be dying when it has a mascot [freebsd.org] like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks [hope-2000.org] and gorgeous babes [hope-2000.org] that BSD has to offer!

    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
  • 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?

    • Re:OpenBSD and m88k (Score:5, Insightful)

      by sl0ppy ( 454532 ) on Friday October 03, 2003 @03:58PM (#7127222)
      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.
      • it was because the cpu was dead, and things didn't work that the attempt was made
        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
    • I can make a dead gcc with zero knowledge of C.
    • Nothing better than working on MS Unix!

    • Re:OpenBSD and m88k (Score:2, Insightful)

      by Anonymous Coward
      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?

      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

    • Not to mention dead compiler.
  • Now that the M88K is extinct, we have gcc 2.95 support for it ;) ... now where did I put that VME box...

  • Protection (Score:4, Funny)

    by WTFmonkey ( 652603 ) on Friday October 03, 2003 @03:55PM (#7127174)
    Notice how CUM, the first parameter, is used unprotected?
    No rubber? God only knows whast the little tramp picked up...

    • Re:Protection (Score:1, Funny)

      by Anonymous Coward

      Elegy For *BSD

      I am a *BSD user
      and I try hard to be brave
      That is a tall order
      *BSD's foot is in the grave.

      I tap at my toy keyboard
      and whistle a happy tune
      but keeping happy's so hard,
      *BSD died so soon.

      Each day I wake and softly sob
      Nightfall finds me crying
      Not only am I a zit faced slob
      but *BSD is dying.

  • why i use openbsd (Score:1, Funny)

    by Anonymous Coward
    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 lapto

  • Cool (Score:4, Insightful)

    by Dysan2k ( 126022 ) on Friday October 03, 2003 @04:08PM (#7127332) Homepage
    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!

  • Oh, catch the hell up. (Score:5, Informative)

    by devphil ( 51341 ) on Friday October 03, 2003 @04:09PM (#7127344) Homepage


    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.

    Unfortunately, gcc, by design, will never inline functions (even if explicitly requested) at -O0. The non-return point had been crossed: gcc had to be fixed.
    [...]
    After compiling gcc 2.95 with gcc 2.8,

    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)

      by Greg Lindahl ( 37568 ) on Friday October 03, 2003 @04:22PM (#7127467) Homepage

      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."

      • 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

    • gcc 3.x is _very_ different than two, to the point that gcc 3 won't compile some things that 2.96 will and vice-versa. IIRC, support for the platform in question was dropped completely in the 3 series.
    • Strange bedfellows. Enterprise legacy software and masochistic hobbyists.

      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)

    by mbessey ( 304651 ) on Friday October 03, 2003 @04:21PM (#7127456) Homepage Journal
    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 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.
    • That's interesting that there are options that don't do anything. Off hand I could see some options still existing because there is some nasty code still out there with some bizarre compile options that were once applicable. Take what I say with a grain of salt, I personally don't know what options they would be, but maybe back in the day there was something silly like -liberal-for-loops. You know... to allow the people who like to do this:

      for(ptr=passed_param;ptr!=NULL;ptr=ptr->next)

      Who knows, but I

  • GCC: "not as hard as one could imagine" (Score:2, Funny)

    by Anonymous Coward
    " 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
  • 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 [brainfuck.ca] back-end here I come!


    • You have no idea how tempted I've been to do exactly that. :-) My one attempted so far was defeated by the needless complexity of the language front-ends (not the same stuff the mi8k article talks about). I think once the new front-end rewrites get merged in, I might have another go...

  • 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...
  • 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!!

  • Inaccessable (Score:2, Insightful)

    by fishybell ( 516991 )
    This is by far the most inaccessable front page article I've ever seen on Slashdot.

    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

    • This article is only truly accessable to the readers who are already familiar with C

      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)

      by dmiller ( 581 ) <djm AT mindrot DOT org> on Friday October 03, 2003 @11:32PM (#7130351) Homepage

      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.

    • 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.

      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.
    • if the article [onlamp.com] 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* ?

      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 /. whipper snapp
  • Christ, folks, if I didn't know better, I'd say you hate *BSD more than you hate SCO.
  • 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 [dragonflybsd.org] only start development
  • 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 do not agree with the poster of the story that "diving into gcc" is far more easy than you might have thought.
    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 ... and its likely also far more the avarage Java geek knows about programming.
    Also: the article does not g

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close