DaemonForums  

Go Back   DaemonForums > DaemonForums.org > News

News News regarding BSD and related.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 31st July 2013
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,883
Thanked 190 Times in 160 Posts
Default Compilers in OpenBSD

An exceptional post detailing compiler choices in the OpenBSD world today:

http://marc.info/?l=openbsd-misc&m=137530560232232&w=2

Enjoy!

Reply With Quote
  #2   (View Single Post)  
Old 1st August 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 201
Thanked 3 Times in 3 Posts
Default

Yes, that was a fantastic post. Saved it away.

I wonder about clang/llvm. I want something as far along as possible to try to learn the changes from C++11. I've been compiling it this week on slackware (the machine won't run OpenBSD yet). My first try, I went with the debug version (debugging info is good, yeah, especially since I took the tip of their source control) and ld wanted 3 GiB. Fine, but I gave up when the install (and object files I had left over) was going to take something over 10GiB. So this morning I started again with the "release" version and it's still building tonight. As my machines go, this one's not that slow (only 5 years old and multicore -- oh shoot, I forgot -j 3, oh well, at least the system's still responsive).

Has anyone ever manually built gcc? Is it the same?

Then clang needs someone else's standard c++ library, right? Plus it requires gcc to bootstrap. I guess these aren't showstoppers, but, I dunno, to me it almost seems like part way along the road to building something like GHC. Okay, maybe that's exaggerating.
Reply With Quote
  #3   (View Single Post)  
Old 1st August 2013
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 322
Thanked 9 Times in 9 Posts
Default

Building gcc is a nightmare...at least if it is done right. You have to build gcc-newver with gcc-oldver, then build gcc-newver with gcc-newver. Not the most efficient use of time, as you can imagine.
__________________
Linux Admin by Profession. OpenBSD user by choice.
Reply With Quote
  #4   (View Single Post)  
Old 1st August 2013
shep shep is offline
ISO Quartermaster
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 592
Thanked 9 Times in 9 Posts
Default

I occasionally glance at the Bitrig project which is based on LLVM's clang 3.1, I have not had the guts to try it though. Their package list has grown to the point that most of Xfce4, Firefox/Xombrero have compiled for the amd64 port
http://mirror2.us.bitrig.org/pub/bit...0723/packages/
Reply With Quote
  #5   (View Single Post)  
Old 1st August 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 201
Thanked 3 Times in 3 Posts
Default

Quote:
Originally Posted by rocket357 View Post
Building gcc is a nightmare...at least if it is done right. You have to build gcc-newver with gcc-oldver, then build gcc-newver with gcc-newver. Not the most efficient use of time, as you can imagine.
Yeah, I guess I was missing the obvious fact that an existing gcc binary (or other C++ compiler) is also a prerequisite for building gcc itself. And there, what, there must be a window of versions you'd have to use to get whatever ISO C++98 features they use now (bound to expand over time -- perhaps eventually to C++11). Now that my clang build's finished I'm thinking it wasn't so bad at all. The dependencies were very minimal -- less than gcc's I think, looking here: http://gcc.gnu.org/install/prerequisites.html (except gcc's dependencies are clang's dependencies transitively, in a way).

So if you're starting from the beginning on a new platform that's not supported yet how do you bootstrap the compiler? You have to cross compile, I guess. It would be interesting if someone somehow kept track of what compilers are the parents of what binaries all the way back. Do our present compilers have as their ultimate parent the original pcc in the 70s or Ken Thompson's original compiler written in assembly? Or is there a more recent C compiler written in assembler (which is written in...?) that's the root of what we have now? Or could it be multirooted if pcc's yacc was based on one thing and the compiler processing yacc's output something else. I guess more likely it would be all rooted at Ken Thompson, maybe his B compiler. Maybe he's having a laugh on us all and played the trick he wrote about in that paper.
Reply With Quote
  #6   (View Single Post)  
Old 1st August 2013
Ninguem Ninguem is offline
Shell Scout
 
Join Date: Jun 2011
Posts: 138
Thanked 0 Times in 0 Posts
Default

One may need to drop to the level of assembly to port a compiler between architectures.
__________________
No signature
Reply With Quote
  #7   (View Single Post)  
Old 1st August 2013
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 322
Thanked 9 Times in 9 Posts
Default

Related FAQ entry:

Can I cross-compile? Why not?

I think "not maintained for general use" is the key thing here. The developers hammer it into place just enough to make a new arch "native build" capable, and then throw away the cross compiler. Not really intended for general use.

Edit - and as long as the compiler is designed in a semi-sane fashion (take the source in, say, C, and emit the equivalent assembly, then assemble to machine code), the compiler doesn't need to be re-written in assembler, it just needs to have a new target arch written into it to permit it to output correct assembler for that architecture. (But I'll grant the fact that this observation is the 10,000 foot view of the problem, and just because a compiler outputs proper assembly for unsupported arch when run on supported arch doesn't mean the compiler can cross-compile itself to make it "native build" capable).
__________________
Linux Admin by Profession. OpenBSD user by choice.

Last edited by rocket357; 1st August 2013 at 05:21 PM.
Reply With Quote
  #8   (View Single Post)  
Old 1st August 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 201
Thanked 3 Times in 3 Posts
Default

I'm not making myself clear. I'm over the idea that moving to clang is difficult because of bootstrapping or dependencies (although I now have something at home that fails to find std::cout when it links a simple C++ hello world -- never mind, I'll do the research myself). Over the course of my post I transition to wondering how compilers get bootstrapped to realizing they must be generated by other compilers, not necessarily running on the same platform, to wondering about what the ultimate root of all these compilers is.

Assembler code is kind of a red herring here. When thinking of an ultimate root I should have either said hand entered machine code or else said manually written assembly code and (arbitrarily?) decided to leave out the assembler in the compiler family tree.

So the ultimate root, the point up the tree where a human directly created the machine code rather than that code (via C, assembler or other intermediate format) being output by another program -- I leave text editor out as a generating program here -- is it Ken Thompson's B compiler, something further back, or something later? Wouldn't it be interesting (for the person looking at the chart, not the person creating it) to have a graph mapping compiler versions and platforms all the way back through each compiler build. For instance, when BSD first started using gcc, they compiled it with pcc? When Bell switched from Ken Thompson's compiler to pcc, they compiled the latter with the former and yacc, which was also compiled with the former? Or are there some other oddities in the tree, e.g. a VAX VMS system compiler in the ancestry?

It's interesting to think (if it's true) that all our C and C++ compilers were ultimately generated, across many levels of indirection as each succeeding compiler was built, by Ken Thompson. Kind of like finding out your family descends from the Mayflower, if you were an American that is. Or maybe a more universally relatable analogy would be to Carl Sagan pointing out our bodies' molecules are from supernovae.

This is the paper I referred to: http://cm.bell-labs.com/who/ken/trust.html From this you wonder if the valiant OpenBSD devs handling compiler issues ever have to find bugs in the compiler that generated the compiler they're seeing problems with. You could imagine the new compiler being bug free (okay, not bug free but not suffering from the bug at issue) at source level but having a bug in its binary caused by the old compiler. I can't even imagine how hard that would be to figure out.
Reply With Quote
  #9   (View Single Post)  
Old 1st August 2013
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 322
Thanked 9 Times in 9 Posts
Default

I've read that paper. David Wheeler's response is a nice followup (albeit many moons later =)
__________________
Linux Admin by Profession. OpenBSD user by choice.
Reply With Quote
Old 1st August 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 201
Thanked 3 Times in 3 Posts
Default

Quote:
Originally Posted by rocket357 View Post
I've read that paper. David Wheeler's response is a nice followup (albeit many moons later =)
"Simply recompile the source code twice: once with a second (trusted) compiler, and again using the result of the first compilation."

Where does this trusted compiler come from? If Ken Thompson's at the root of all C compilers what if he is secretly an evil genius (or slightly less paranoid, what about generations between your so called trusted compiler and his, supposing we all trust him)?
Reply With Quote
Old 6th August 2013
Ninguem Ninguem is offline
Shell Scout
 
Join Date: Jun 2011
Posts: 138
Thanked 0 Times in 0 Posts
Default

Check the math.
At the lowest/basest level, programming is math. CPU flags are math.

It all starts as a simple logic or-nor circuit and works from there.
__________________
No signature
Reply With Quote
Old 6th August 2013
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 563
Thanked 14 Times in 13 Posts
Default

Quote:
Originally Posted by Ninguem View Post
Check the math.
At the lowest/basest level, programming is math. CPU flags are math.

It all starts as a simple logic or-nor circuit and works from there.
One could also argue that at a lower level, it's physics, if we're talking about software running on real hardware.

One could also argue that, philosophically, math = physics. If we dig down deep enough, we don't know what anything will do.
Reply With Quote
Old 6th August 2013
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,883
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by Ninguem View Post
At the lowest/basest level, programming is math. CPU flags are math.
You might be interested in a classic missive written by Niklaus Wirth, "Algorithms + Data Structures = Programs":

http://www.amazon.com/Algorithms-Str...ata+structures

Most college and/or university libraries should have a copy. Highly recommended.

Last edited by ocicat; 6th August 2013 at 07:22 PM. Reason: clarity
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Oracle gooses Studio compilers for Solaris, Linux J65nko News 0 20th December 2011 08:17 AM
Delete compilers to cross compile revzalot OpenBSD Installation and Upgrading 9 28th August 2009 08:06 PM


All times are GMT. The time now is 08:21 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick