Porting LLVM, clang et al. to GNU/Hurd | Hacker News Reader

Porting LLVM, clang et al. to GNU/Hurd

lists.cs.uiuc.edu

52 pointsredDragon20 comments

I'm struggling to imagine the audience for this; other than compiler researchers, LLVM's users seem to be primarily those who want to avoid using GNU code (in the form of gcc, which while not without its flaws is still more featureful and generally produces more performant code) for whatever reason (e.g. Apple), while Hurd's only users are GNU devotees.

The clang static analyzer is the best you can find in the FOSS world and is constantly improving. LLVM itself is multi-target with a single compiler binary (llc), always handy for embedded developers. LLVM can target GPUs, and the resulting binaries wouldn't care if the host OS was Linux or Hurd. Clangs diagnostics are often better than GCC's but the GCC project is catching up fast in that area. Finally, LLVM offers a JIT that projects can use as a library. GCC offers compatibility, large target support, lots of compiler extensions, and great code generation.

LLVM is also useful for runtime code generation (e.g., in rubinius, a Ruby implementtion), and as a prepackaged optimizer for other compilers (e.g., GHC, the Glasgow Haskell compiler). Both those packages have users outside the compiler research community...

btw, the current dev version of clang is broken for months. It crashes on a failed assertion when I'm trying to compile erlang or mplayer+ffmpeg. It also failed to build racket - the resulting binary eats all the memory and dies.) Gcc does the job. So, it seems that while running after C++ features they ruined the plain old C.)

It works great on my C sources; have you reported the failure(s)?

  clang  -m64 -march=native -mtune=native -O3 -I/home/schiptsov/Compile/otp/erts/x86_64-unknown-linux-gnu    -D_GNU_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS  -Ix86_64-unknown-linux-gnu/opt/smp -Ibeam -Isys/unix -Isys/common -Ix86_64-unknown-linux-gnu -Izlib  -Ipcre -Ihipe -I../include -I../include/x86_64-unknown-linux-gnu -I../include/internal -I../include/internal/x86_64-unknown-linux-gnu -c beam/beam_emu.c -o obj/x86_64-unknown-linux-gnu/opt/smp/beam_emu.o
  clang: /home/schiptsov/Compile/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2050: bool <anonymous namespace>::LoopVectorizationLegality::canVectorize(): Assertion `TheLoop->getLoopPreheader() && "No preheader!!"' failed.

  CC	libavcodec/flashsvenc.o
  clang: /home/schiptsov/Compile/llvm/lib/Analysis/LazyValueInfo.cpp:613: bool <anonymous namespace>::LazyValueInfoCache::solveBlockValueNonLocal(<anonymous>::LVILatticeVal &, llvm::Value *, llvm::BasicBlock *): Assertion `isa<Argument>(Val) && "Unknown live-in to the entry block"' failed.

LLVM and Clang have nightly buildbots that check for regressions. They are quite fastidiously maintained. The project would really appreciate your help and you can do so by submitting a bug report with steps to reproduce and build artifacts. The bugfix will contain a test case, likely a minimal reduction of your repro, that will be run in the buildbots to make sure that you never see the same problem again.

And I do not believe that they have sacrificed anything to support both C and C++ (including partial support for their '11 variants). The codebase is abstracted away from the C/C++ differences where it makes sense. It is an impressively comprehensible compiler!

http://llvm.org/bugs/

They had a working version to test on? Surely such a mythical beast doesn't exist?

Of Hurd? Debian has had an in-development version since 1998: https://en.wikipedia.org/wiki/Debian_GNU/Hurd

There's also Arch Hurd: https://en.wikipedia.org/wiki/Arch_Hurd

Gentoo is also listed: http://www.gnu.org/software/hurd/hurd/running/distrib.html

It does, it is just that most people tend to ignore Hurd anyway.

Personally I want Hurd and Minix 3 to gain support, as I feel that micro-kernels are the way to improve operating system security.

The only successfully commercial attempts so far have been Symbian and QNX.

Symbian was a microkernel?

Symbian ran on EKA2[1], which was a micro-kernel, although since Symbian included device drivers it wasn't technically a true microkernel[2].

1: https://en.wikipedia.org/wiki/EKA2

2: https://en.wikipedia.org/wiki/Symbian#Symbian_kernel

I was fairly sure that NT was originally going to be a microkernel, but it ended up being really slow, so they had to push everything into a more monolithic architecture.

My understanding that this was mainly about moving graphic drivers back into kernel space from user space (circa NT 4.0).

and now they tout it as a http://en.wikipedia.org/wiki/Hybrid_kernel

NT derived from Mica, DEC's microkernel OS project for their research RISC architecture PRISM. When DEC cancelled Mica along with PRISM — flirting briefly with MIPS before finishing Alpha — project lead Dave Cutler and some of his team took it to Microsoft. (The eventual settlement had MS support NT on Alpha until DEC collapsed from mismanagement.)

\def\Linux{GNU/Linux}

\def\Hurd{GNU/Hurd}

  \usepackage{xspace}
  \def\Linux{GNU/Linux\xspace}
  \def\Hurd{GNU/Hurd\xspace}

Reply on news.ycombinator.com