[cfe-dev] Porting LLVM, clang et al. to GNU/Hurd

[Thomas Schwinge]

Hi!

At night, when having my GNU Hurd maintainer hat on, I'm currently
working on porting LLVM, clang et al. to x86-class systems using the GNU
Hurd as their kernel, <http://www.gnu.org/software/hurd/>.

In the following, I'll just use LLVM to refer to the whole suite of
tools.


To some extent, LLVM already works on GNU/Hurd; thanks for constructing
it in a portable fashion.  From LLVM's perspective, the Hurd mostly is
just another Unix-like system to be ported to, very similar to those
using the Linux kernel; and a bunch of fixes are in the "know what to do"
category, but for others I'd like to solicit your input first.


At very few places only, LLVM (as most other software) needs to know
which specific operating system kernel it is running on.  Most of the
details that deal with interfaces specific to operating system kernels
are abstracted in the system's C library.  So it happens that once a C
library is available, most "Unix" software can be compiled without really
caring about the system's kernel.  So, in summary, LLVM (as most other
software) does not really care about the operating system kernel (Linux,
Hurd), but rather cares about the operating system's user-space
interface, POSIX/Unix, as defined by the C library.

Both Linux-based and Hurd-based systems typically use the GNU C library
(glibc), which itself largely follows POSIX/Unix.  GNU/Linux and GNU/Hurd
systems also share the concept of how they're bundled: in distributions,
such as Debian GNU/Linux, respectively Debian GNU/Hurd -- the latter one
being the most prominent and advanced one offering support for the Hurd.
(By the way, Debian also support a system using the FreeBSD kernel,
Debian GNU/kFreeBSD.)

LLVM already has support for this concept, albeit under the name of, for
example, LinuxDistrib ([clang]/lib/Driver/ToolChains.cpp).  Now, instead
of duplicating all that code for "non-Linux-but-still-glibc"
distributions, what I would like to do is simply reuse the existing code,
renaming LinuxDistrib to [something]Distrib (and likewise for similar
cases), and then introduce specializations for the respective operating
system kernels in the very few places where it is needed, such as which
standard preprocessor defines there are
([clang]/lib/Basic/Targets.cpp:LinuxTargetInfo::getOSDefines), or how the
target specifier maps to include and library directories
([clang]/lib/Driver/ToolChains.cpp:Generic_GCC::GCCInstallationDetector::CollectLibDirsAndTriples,
for example).

The question is what LinuxDistrib, LinuxTargetInfo, and a few others
should be renamed to; we need new names to mean something like "not
depending on the Linux kernel but still glibc".  In GCC we use files such
as gnu-user.h for this purpose, meaning GNU user-space (as defined by
glibc; independent of the system's kernel), and these are then
complemented by linux.h and gnu.h for adding the Linux, respectively
Hurd-specific bits.  Would that be fine for LLVM as well, that is, rename
LinuxTargetInfo to GNUUserTargetInfo, and so on?  (Though, I'm not too
happy with GNUUserDistrib.)


After "finishing" (whatever that is) ;-) this port, I'll also continue to
be available for maintaining it.


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130110/8f4766ba/attachment.sig>