Port to other Operating Systems

Hello all,

Pardon me if this has already been covered elsewhere, however I have not been able to find such documentation. Is there a consolidated set of documentation that clearly explains what's necessary to port LLVM to other OSes & how to add support for building executables (& libraries) for those OSes? I'm searching through the source in an attempt to understand what needs to be done, but this codebase isn't the most simple of codebases. Thanks for any potential help!

Regards,
Apollo D. Sharpe, Sr.

From: llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] On Behalf Of Dee
Sharpe via llvm-dev
Sent: Tuesday, October 11, 2016 8:23 AM
To: llvm-dev@lists.llvm.org
Subject: [llvm-dev] Port to other Operating Systems

Hello all,

Pardon me if this has already been covered elsewhere, however I have not
been able to find such documentation. Is there a consolidated set of
documentation that clearly explains what's necessary to port LLVM to other
OSes & how to add support for building executables (& libraries) for those
OSes? I'm searching through the source in an attempt to understand what
needs to be done, but this codebase isn't the most simple of codebases.
Thanks for any potential help!

I assume you are interested in hosts (not targets). I'm not aware of any
documentation per se. If your host OS is not Unix-like or Windows-like,
it will probably take some doing. The first hurdle I can imagine is just
getting the build system to work for you; we use CMake, which might or
might not support your OS out of the box. After that you'd likely need
to do some work in the source itself; we try to isolate much of the
platform-dependent stuff in llvm/lib/Support but I think there are some
other places scattered around that are still under conditional compilation.

+John Reagan who is point man for a project to (ultimately) bootstrap
Clang for OpenVMS. He might have a better idea what's needed, although
last I talked to him they were going to use cross-compilation for quite
some time.

Hope this helps,
--paulr

Hi,

for a first impression you can have a look at this FOSDEM talk: FOSDEM 2016 - Porting LLVM to a new OS

Regards,
Kai

On Ubuntu 16.04 I just did:

nm -D -u /usr/lib/llvm-3.8/bin/clang | grep -v llvm | grep -v LLVM | grep -v _Z

I got 53 results:

U abort
U asctime
U calloc
U chdir
U close
U ConvertUTF8toUTF16
U ConvertUTF8toUTF32
U __cxa_atexit
U __cxa_guard_acquire
U __cxa_guard_release
U __cxa_pure_virtual
U __errno_location
U exit
U __fprintf_chk
U free
U getenv
U getNumBytesForUTF8
U getuid
w gmon_start
U isLegalUTF8Sequence
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
U __libc_start_main
U localtime
U malloc
U memchr
U memcmp
U memcpy
U __memcpy_chk
U memmove
U memset
U __popcountdi2
U __printf_chk
w __pthread_key_create
U qsort
U realloc
U __realpath_chk
U __snprintf_chk
U __stack_chk_fail
U stderr
U strchr
U strcmp
U strdup
U strlen
U strncmp
U strpbrk
U strrchr
U strstr
U strtol
U strtoul
U time
U __xstat

Some of those are still provided in llvm itself (e.g. the UTF8 stuff) but most of the rest are dead standard C library things – not even POSIX. Without thinking about it too much, the least portable and hardest to fake look like time, localtime, and getuid. Which means: not very hard.

Build system is another matter entirely…

That’s clang, but I don’t expect an optimizer to be very system dependent :slight_smile:

Thank you. Do you have an idea of which specific files I need to look into for porting hosts & targets? Is there a central set of files, or is the implementation spread out across the source tree?

As part of our port of OpenVMS to x86-64, we are using LLVM with our own frontends on OpenVMS Itanium. We are writing a converter between our old backend's IR and the LLVM IR. We can cross-compile (hosted on OpenVMS Itanium) and link/execute on x86-64 CentOS. At present, we pass over 88% of our C test suite.

Porting starts with being able to compile the code. Since we are stuck with a C++03 (sorta) compiler that uses an EDG frontend and the Intel Itanium backend, we had to start with an older LLVM release that did not use C++11 source code. We went with 3.4.2.

I was able to build LLVM 3.4.2 with our old C++ compiler with little issues (I think I had to add about 5 or so "#ifdef __vms" to some modules in lib/Support). There were a handful of missing RTL interfaces due to OpenVMS not having complete C99 header support (that is being worked on now). I wrote a bunch of empty jackets to work around the missing symbols. So far, I haven't had to come back and fill in ANY of them (I'm sure I will bump into them at some point).

And we'll build clang 3.4.2 using the same old C++ compiler and then hopefully once we have working OpenVMS x86 systems, I can use that clang to cross-compile a newer clang/LLVM pair (perhaps in several small step or all at once - we'll just wing it). And we'll need a working cmake on OpenVMS by that time. From peeking at the code, that might be the harder part. We might have to just grab cmake generated Makefile's from a Linux box and hack our way to daylight. Do you have cmake? Do you have some sort of bash shell and gnu tools? (OpenVMS has a "GNV" package with a bash shell, fileutils, diffutils, make, grep, awk, etc. which really reduces the effort)

Compiling the code is just a start however. You'll eventually want to link those objects you create. What OS are you using and what hardware platform?

As part of our port of OpenVMS to x86-64, we are using LLVM with our own frontends on OpenVMS Itanium. We are writing a converter between our old backend's IR and the LLVM IR. We can cross-compile (hosted on OpenVMS Itanium) and link/execute on x86-64 CentOS. At present, we pass over 88% of our C test suite.

Porting starts with being able to compile the code. Since we are stuck with a C++03 (sorta) compiler that uses an EDG frontend and the Intel Itanium backend, we had to start with an older LLVM release that did not use C++11 source code. We went with 3.4.2.

I was able to build LLVM 3.4.2 with our old C++ compiler with little issues (I think I had to add about 5 or so "#ifdef __vms" to some modules in lib/Support). There were a handful of missing RTL interfaces due to OpenVMS not having complete C99 header support (that is being worked on now). I wrote a bunch of empty jackets to work around the missing symbols. So far, I haven't had to come back and fill in ANY of them (I'm sure I will bump into them at some point).

And we'll build clang 3.4.2 using the same old C++ compiler and then hopefully once we have working OpenVMS x86 systems, I can use that clang to cross-compile a newer clang/LLVM pair (perhaps in several small step or all at once - we'll just wing it). And we'll need a working cmake on OpenVMS by that time. From peeking at the code, that might be the harder part. We might have to just grab cmake generated Makefile's from a Linux box and hack our way to daylight. Do you have cmake? Do you have some sort of bash shell and gnu tools? (OpenVMS has a "GNV" package with a bash shell, fileutils, diffutils, make, grep, awk, etc. which really reduces the effort)

Good to know!

Compiling the code is just a start however. You'll eventually want to link those objects you create. What OS are you using and what hardware platform?

The OS is Pyro, it's a fork of Syllable, which itself is a fork of AtheOS. We're prepping to move from x86 to x86_64. We thought that this would be the best time to go ahead & move from our outdated GCC to LLVM. I realize that we should do these things in stages. Currently, our GCC support is 4.1.2, which is horribly outdated. So, the first step is to port our OS as a target, so we can build our binaries on a FreeBSD host. Once we're able to build the OS with LLVM, we'll worry about porting LLVM to Pyro as a host.

The OS is Pyro, it's a fork of Syllable, which itself is a fork of
AtheOS. We're prepping to move from x86 to x86_64. We thought that this
would be the best time to go ahead & move from our outdated GCC to
LLVM.
I realize that we should do these things in stages. Currently, our GCC
support is 4.1.2, which is horribly outdated. So, the first step is to
port our OS as a target, so we can build our binaries on a FreeBSD
host.
Once we're able to build the OS with LLVM, we'll worry about porting
LLVM to Pyro as a host.

--
Regards,

Apollo D. Sharpe, Sr.

So you want to host on FreeBSD and target Pyro.

Since you are using some gcc version for Pyro, does that mean you are using
standard ELF/DWARF? Where does your linker come from? Can it handle the
appropriate relocations?

Looking at your somewhat outdated www.pyro-os.org, Pyro looks essentially
UNIX like given the software packages listed. Looking further at the Syllable
website confirms that.

I don't see anything particularly difficult unless you've added/modified the
ELF/DWARF/relocations in the object or image files. Just tell LLVM that you
are x86-64 Linux and see what you get. For instance, I haven't added OpenVMS
as a triple, we use the x86-64 Linux triple. We might have enough differences
that I might lobby for my own triple, but I'm not anywhere near that place
yet.

John

So you want to host on FreeBSD and target Pyro.

Yes, with the goal of moving hosting to Pyro.

Since you are using some gcc version for Pyro, does that mean you are using
standard ELF/DWARF? Where does your linker come from? Can it handle the
appropriate relocations?

Yes, we are using standard ELF/DWARF. Our entire toolchain is GNU, something that we're hoping to change by moving to LLVM. Currently, we can handle relocations, however there ARE issues with our implementation -it's incomplete.

Looking at your somewhat outdated www.pyro-os.org, Pyro looks essentially
UNIX like given the software packages listed. Looking further at the Syllable
website confirms that.

Yes, we're UNIX like, but we aren't UNIX. We have POSIX compatibility, but it's merely a means to an end, not a priority.

I don't see anything particularly difficult unless you've added/modified the
ELF/DWARF/relocations in the object or image files. Just tell LLVM that you
are x86-64 Linux and see what you get. For instance, I haven't added OpenVMS
as a triple, we use the x86-64 Linux triple. We might have enough differences
that I might lobby for my own triple, but I'm not anywhere near that place
yet.

Ok, that makes a lot of sense. I think I'll use that approach, though it'll probably be the x86-64 FreeBSD triple. I wasn't aware that lobbying was necessary, however, I'm very new to dealing with LLVM.