[llvm-dev] Port to other Operating Systems
Dee Sharpe via llvm-dev
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.
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Robinson, Paul via llvm-dev
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev...@lists.llvm.org] On Behalf Of Dee
> Sharpe via llvm-dev
> Sent: Tuesday, October 11, 2016 8:23 AM
> To: llvm...@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!
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
Kai Nacke via llvm-dev
for a first impression you can have a look at this FOSDEM talk:
https://archive.fosdem.org/2016/schedule/event/llvm_to_new_os/
Regards,
Kai
Bruce Hoult via llvm-dev
A. D. Sharpe via llvm-dev
into for porting hosts & targets? Is there a central set of files, or is
the implementation spread out across the source tree?
--
John Reagan via llvm-dev
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?
A. D. Sharpe via llvm-dev
> 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?
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.
--
John Reagan via llvm-dev
> 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
A. D. Sharpe via llvm-dev
> 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?
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.
--
Regards,
Apollo D. Sharpe, Sr.
_______________________________________________