LLVM progress update

vvuk

Administrator
Aug 25, 2021
39
33
18
tl;dr: 16 Jan 2023 -- I'm dumb and screwed up updating the rpms in the below location, and did this in a hurry. Updated now! Correct latest version is 14.0.6 (not 14.0.0-pre6)

tl;dr: 31 Dec 2022 -- see later in thread for details, latest RPM builds based on llvm 14.0.6 are at:

https://misc.bitops.com/llvm-rpms/

There is also a yum repo available; the repo file is at:

https://misc.bitops.com/vlad-sgug-extras/vlad-sgug-extras.repo

----------------

tl;dr: 11 Oct 2021 -- see full thread for details, but latest builds are at:

http://misc.bitops.com/irix/llvm-irix-101121.tar.gz
http://misc.bitops.com/irix/llvm-gcc-includes.tar.gz

-----------------

Hey folks -- I've been continuing aurxenon's earlier work on getting LLVM 12 ported to IRIX, and wanted to post a quick update. Things have progressed to where LLVM/Clang can self-compile itself targeting IRIX, using libc++ and its own embedded compiler runtime & crt; in other words, no gcc or binutils. The new target is also relatively "clean". There are very few hacks involved, which should make it easy to maintain going forward.

Unfortunately there's currently what looks like a non-IRIX-specific mips codegen bug -- see https://bugs.llvm.org/show_bug.cgi?id=51958 for details. This ends up causing `lld` to crash on irix, because it happens to hit this exact situation. However, clang runs successfully to compile and assemble object files:

[sgugshell vladimir@tezro tmp]$ uname -a
IRIX64 tezro 6.5 07202013 IP35 mips IP35 Irix
[sgugshell vladimir@tezro tmp]$ /usr/sgug/llvm/bin/clang -O2 -c hello.c -v
IRIX clang version 12.0.0 (git@github.com:vvuk/llvm-project 5445a15e882693d643b55b7cf257b2c2f4d046b0)
Target: mips64-sgi-irix6.5
Thread model: posix
InstalledDir: /usr/sgug/llvm/bin
(in-process)
"/usr/sgug/llvm/bin/clang-12" -cc1 -triple mips64-sgi-irix6.5 -emit-obj --mrelax-relocations -disable-free -main-file-name hello.c -mrelocation-model pic -pic-level 1 -fhalf-no-semantic-interposition -mframe-pointer=all -fno-rounding-math -mconstructor-aliases -mllvm -mmips-pc64-rel=false -fno-use-init-array -femulated-tls -target-cpu mips3 -target-feature -noabicalls -target-abi n32 -mfloat-abi hard -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/sgug/llvm/lib/clang/12.0.0 -internal-isystem /usr/sgug/llvm/lib/clang/12.0.0/include -internal-isystem /usr/lib/clang/mips64-sgi-irix6.5/include-fixed -internal-isystem /usr/lib/clang/mips64-sgi-irix6.5/include -internal-isystem /usr/include -O2 -fdebug-compilation-dir /usr/people/vladimir/tmp -ferror-limit 19 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o hello.o -x c hello.c
clang -cc1 version 12.0.0 based upon LLVM 12.0.0 default target mips64-sgi-irix6.5
ignoring duplicate directory "/usr/sgug/llvm/lib/clang/12.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/sgug/llvm/lib/clang/12.0.0/include
/usr/lib/clang/mips64-sgi-irix6.5/include-fixed
/usr/lib/clang/mips64-sgi-irix6.5/include
/usr/include
End of search list.



Same bug may be lurking somewhere inside though; going to see if I get traction from LLVM folks to fix it. There's still a little more work to be done, mainly around cleaning up how the build is done and some aux things in libc++ but I expect there will be a working tarball and rpm build in the next few weeks. I have verified that LLVM properly generates multiple GOT tables, which means that compiling large software -- such as llvm itself -- will be possible without running into gcc/binutils bugs!
 
Last edited:

Elf

Storybook / Retired, ex-staff
Feb 4, 2019
792
252
63
Mountain West (US)
Excellent work, and I'm glad to see a solution for the multi-GOT issue could finally be in reach :)

Thank you for sharing the update!
 

vvuk

Administrator
Aug 25, 2021
39
33
18
Hi all! I just got a working clang that's able to self-compile itself, and has been able to compile a bunch of things I've thrown at it.

You'll need:
http://misc.bitops.com/irix/llvm-irix-093021.tar.gz
http://misc.bitops.com/irix/llvm-gcc-includes.tar.gz

untar both in /, they'll create /usr/sgug/llvm and /usr/lib/clang (with some includes). Both of this stuff will be fixed, very soon there will be a single tarball with /usr/llvm, as well as a sgug RPM.

You'll have to add /usr/sgug/llvm/bin to PATH, and /usr/sgug/llvm/lib/mips64-sgi-irix6.5-gnuabin32 to LD_LIBRARYN32_PATH and
and /usr/sgug/llvm/lib/mips64-sgi-irix6.5 to LD_LIBRARY64_PATH for libc++.

The default target is mips64-sgi-irix6.5-gnuabin32, i.e. the N32 abi. If you set -target=mips64-sgi-irix6.5, that will build for the 64-bit ABI. Both should work. This isn't a final build of any kind, there are still some tweaks to do, and some packaging fixes -- as well as cleaning up the borrowed gcc fixed-includes headers.

Please let me know what breaks!
 
  • Like
Reactions: omljud and Elf

Elf

Storybook / Retired, ex-staff
Feb 4, 2019
792
252
63
Mountain West (US)
Excellent work, and very interesting to hear about working 64 bit support. This whole project has gotten me interested in the details of linking/loading and executable formats :)
 

vvuk

Administrator
Aug 25, 2021
39
33
18
> that's a no-go. /usr/lib is a fundamental system folder. no other stuff should be in there.

As I said -- "this stuff will be fixed" as well as "there are some packging fixes".

But /usr/lib isn't some magic sacrosanct place. Non-core things place things there are all the time -- e.g. /usr/lib/Showcase, /usr/lib/WorkShop etc., though for simplicity on irix it's better to keep things in a unified place (e.g. /usr/llvm) when it comes from a tarball, to make uninstalling easier and not leave cruft behind.
 

Unxmaal

Administrator
Feb 8, 2019
98
60
18
@vvuk I'm very thankful that you and @aurxenon spent so much time and energy porting LLVM to this antique OS. Others have claimed that this would be impossible.

@foetz Why should we give a shit about installing things in /usr/lib for a brief period before it gets properly packaged? I mean, on the list of Sins Against IRIX, RSE uses RPM to manage packages, so how is this any worse?
 
  • Like
Reactions: chulofiasco

vvuk

Administrator
Aug 25, 2021
39
33
18
Some updates -- this clang is successfully busily compiling itself natively on IRIX, so I would call this "ready for use, despite known bugs". There is some condition that causes clang to emit an unaligned mem op that I'm having a hard time tracking down (I mean I know where, but I don't understand why). I've worked around this in clang itself by just turning on MIPS_FIXADE and letting the kernel fix it up, see below.

Latest builds: (Will update top post as well)

http://misc.bitops.com/irix/llvm-irix-101121.tar.gz
http://misc.bitops.com/irix/llvm-gcc-includes.tar.gz

You'll need an updated llvm-gcc-includes, hopefully the last one. You'll want to blow away /usr/lib/llvm and /usr/lib/clang from previous builds; everything goes into /usr/llvm, with the exception of the fixed includes, which are in /usr/lib/clang.

Known issues:
- I don't trust the 64-bit codegen. There's some misalignment I've seen in libc++ that causes a 64-bit clang itself to not work. But simple things may work fine.
- Misaligned memory op codegen. If someone builds something with this and gets a SIGBUS, PLEASE PLEASE send me your source so that I can reproduce it (right now I'm working to reproduce with clang itself which is "not small"); and then modify your source to enable kernel fixups via:

#include <sys/sysmips.h>
extern "C" int sysmips(int, int, int, int);

... somewhere at the start of main() ..
sysmips(MIPS_FIXADE, 1, 0, 0);
 

vvuk

Administrator
Aug 25, 2021
39
33
18
An update from Clang-land! I'm banging my head a bit in getting clang + lld to generate debug info and symbol info in a way that dbx (and from there SpeedShop etc) can recognize. I think I understand what's missing -- there's a good chance dbx etc. really want the magic symbols like _end _fbss etc. in place -- but now I'm having trouble getting lld to spit things out in a way that rld can actually find these symbols. Same old problem as before; if I could see what rld was doing this would be so much easier :)

But progress is still being made, just slower a bit. And I need to get dbx working to be able to sanely debug the misaligned stack issue.
 
  • Like
Reactions: Elf

Elf

Storybook / Retired, ex-staff
Feb 4, 2019
792
252
63
Mountain West (US)
It would be a bunch of work porting over the libs, not all the crates might be compatible etc., but, I noticed this the other day:
Code:
% rustup target list | grep mips
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
%
;)
 

vvuk

Administrator
Aug 25, 2021
39
33
18
Updated with new RPMs -- these are versioned `pre1`, which is what they should have been in the first place. If you installed my bad-versioned rc, upgrade with `--force -Uvh`.

Soon there will also be two tarballs (once they finish uploading) -- one for a linux cross compiler, and one just a bare tarball of the full irix native compiler.
 
  • Like
Reactions: jenna64bit

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu