 So as you can probably see, we're having some very interesting technical experience with them. So I think you can all play it. If you want to have some, I'm going to have to try and present all the laptop, showing you the slides from here. You can read really strong letters. So I don't know whether you're going to get much context. If you've got your own laptop, you can download the slides, try and follow them with anything there. I'll try my best, and hopefully we can get some differential team to come back and do that. So I will try my, most of the time, just talk to you. A lot of the details are actually quite difficult to read on the slide anyway, and I can probably get most of the information across to you by just talking. So it is some kind of weird, impromptite thing. Quite weird. Yes. I think I'm sufficiently uncoordinated. Okay. So what was I intending to talk to you about today? Nothing else. This sort of stemmed from an adventure I had trying to cross-compile the compiler RT library of some various different versions of BAM. And I thought after going through the various bits of pain and trying to get Seamaker to work properly which is actually probably the most difficult bit of the whole endeavor. And then sort of just saying, well, okay, how is this actually working? Why is this strange error message coming up? And I went on a bit of a deep dive into the driver to work out how this actually works. And then tried to write some of this artwork. So I've submitted a really manual like page on how to cross-compile the compiler RT and find on the LLVN documentation sort of side. So I thought, okay, I've done all that work. Can I generalize that, put it into a presentation and try and talk to you about it? I think that's what I found that after investigating this for another couple of weeks, I think I knew less when I came out of the two weeks than I did when I did. But I'll try and do my best to try to get at least across some of the general principles. I'll cross-compilation how it works within Climb and LLVN. So the first thing I'm going to start with is some definitions of what I'm going to use. For those of you at the back, I've said it's this thing, host, and that's one app by the host system. That's the sort of one that you're running the compiler on. The target is the sort of system that you're cross-compiling for. So most typical example would be your host is x8664. Your target is some embedded microcontroller, something like an ARM type of thing. Oh, by the way, I'm using ARM in AR64 a lot. It's currently working for the NARU. That's what I'm familiar with. A lot of the same principles that apply to other architectures as well, that sort of thing. I'm just using it. So if I had to say the word native compilation, I mean the host is the same target. If I say cross-compilation, I mean the host is different than the target. If you look at the configured build system, they've got a separate host target build that's separate again. But I'm not going to use that amount in other detail. That's sort of where you have you're building a compiler on one architecture that runs on a different architecture that cross-compiles for a different architecture. That's the thing. So why might you want to go through the pain of cross-compilation if it's all the big nightmare? Well, the whole reason for it is that there's one scenario where it's even more of a nightmare compiling natively. And then there's another scenario where it's your only option. So for example, a device on the top that I've got here is a picture of a Raspberry Pi. You can run GCC. You can run a plan of a Raspberry Pi. If you want to try compiling, say an LLVM and plan on a Raspberry Pi, you're in for a whole load of cash and it will take an awful long time to run the test, to run the test and it will take several hours. So if you can cross-compile that on a very big, fast x86 server you can get your build times down you can iterate more quickly that type of thing. So the first reason you might want to do cross-compilation is just that it's so much faster on a big server than it is on a smaller middle device. So if you run one of these BGC microvix it's a Cortex M0 it's probably less than 64k on the actual board there's no way you're going to run a C compiler on that. So with some cross-compilation it's your only option there. And similarly, I've seen one of the I'd say you can't run a compiler on a Gp yet. I'm sure you won't. Okay, so what I've got here is a diagram of some of the things that you might want to be concerned about with your cross-compiling. As well as actually doing the compilation itself you've also got libraries. This can be a simple embedded system this is probably just static libraries that have been pre-compiled or something a bit more complicated like a embedded Linux application you might have shared libraries. Shared libraries are especially interesting it's very difficult to mix up static libraries in a hosted target but it's a lot easier to mix up shared libraries on the host platform and the target platform you've got to make sure that you get those right. In particular there's an option called R-Cath that you can give a link to which basically says this is where you find your shared libraries and when you're cross-compiling you want the target to find your shared libraries to be valid on your target platform not on your host platform otherwise all sorts of things will go wrong at that point. Looks like in a few moments I've got my slides on a a on a little disc so hopefully it's what will go across from there. So may come back to that later. Thank you very much. So what we've got is this slide. As I mentioned before building an application is not just the compiler you've also got to have a link you might also have to have other tools as well and in particular you've got to convince your build system on your host to actually cross-compile and that's actually quite often the most difficult step because a lot of these systems have got tests to say does your compiler do something sensible and that initial check that does your compiler do something sensible often tries to fight you with every possible step so getting past that step is often the beautiful screen. Okay, yeah, thank you. Awesome. Awesome. Thank you very much. Thank you. Thank you very much. One of the things I sort of thought initially in this campaign I said let's just say what the recent cross-compilation options were and how to sort of put it through from there but it's not really that much different in GCC in that regard so what I've sort of tried to concentrate on is what makes a client different from GCC and what some of the things you might need to do to try to generate some of the libraries that GCC might use. The interesting part about the client is that it has all of the targets compiled in by default so if the kind of comes with your distribution you can say target x86, target arm, target mix and it will produce an output for that and that's probably less useful for the general developer if you've only got small number of types. It's actually brilliant for a compiler development because one of the first things you want to do is say what do this look like for this project? It's not for this one. But that also has a down side in that when you have a compiler that you compile a build time, ground time that you want to play then with the actual options tasks in your options are quite relative I think that's around that whereas in a client where it's sort of saying well I can also compile this architecture this architecture I can try and update windows but I'm not really yet with the client there's a lot more configuration options okay I'm sorry so the people online got nowhere to have our pictures oh well it's a comedy right maybe I'll find some of the sheets through people so first thing we have to do with planning is tell a compiler what to compile for so when you type client on the client line normally you're getting what's called default target triple whereas when you're doing cost compilation you have to explicitly give a triple and give all that to the client so I'll explain if it won't have a target triple on the next slide now one of the things about being a developer you've got quite a bit of I think that's just a poor and sweet problem unlike say a DGCC toolchain that you might have cost compilation toolchain that you might not know there's no such equivalent to LODM as far as I know there may be some companies that are attempting to motion all the libraries and everything up but so far you can't just build with the LODM project and get a C library which is the most important missing component you can get quite a lot of the tools say just downloading the LODM source sort of by re-release but you can't get to everything so some of the library dependencies aren't there so for example so here's my sort of brief spreadsheet about what things are included with LODM what's the equivalence that sort of thing Mark, if it's in orange yes these tools exist they may not be as good as the equivalence, they're more sort of developed tools if you have a toolchain based on LODM you may not get those tools that's like the equivalent of almost done result which is what you would use to disassemble your library there's another way to disassemble it won't disassemble the same way it's going to be much done those tend to be aimed at developers and not for users the most important missing part is the C library so you have to replace that or find something to get used to your target the stuff that is in the box obviously clans the assembler is not separating clans each target has its own I don't know whether all in three targets have it built for the majority LODM is natively across liquor it doesn't support all of the targets that are if you are supported you're in the club it should work for you live on wine it's a kind of winding library that's currently used in the world Lipsy got a BBI Lipsy got a BBI Lipsy got a BBI Lipsy got a BBI typically as a sort of end consumer you kind of attend those Lipsy Lipsy got a BBI they kind of they kind of the implementations of new and delete and the sort of mechanics of doing a function on wine they're not the standard library whereas Lipsy Lipsy Lipsy Lipsy Lipsy Lipsy there's probably lots of detail below the ice okay one of the first things you have to do when you're using parameters across a code is you have choice choice can be a good thing or a bad thing if you don't care, best stick to defaults so typically what will happen is on the Linux targeting system you'll end up with defaulting to the GCC component so even if you have to go to compiler RT by default the client will look for Lipsy Lipsy that actually makes quite a lot of sense if you're targeting a Linux system and the Lipsy Lipsy will already be open in various other minutes will already be on your system so unless there's a particular reason you want the LLVM versions it's best to stick with the platform default but you can obviously make those certain choices there so like I won't bother reading up the whole slide on there but certainly this C library choice can affect the target I promise I'll get on to the target triple this is perhaps the most important user option that you might face when you put it past confirmation so I say triple there's obviously way more than three the actual you can count on there it's really kind of broad on top of all of the triple I've believed it's called a triple based on the original configure triple it's kind of grown out from there so the most important one I think is definitely arch so that would be something like arm lips that type of thing sub arch is kind of I'd say it's mostly an arm thing I think there's one other architecture that has a sub arch but this is where you do things like rv7n or cortex n0 rv7a cortex n0 so typically you don't have sub arch one of the things I've got if you miss any of these out you'll get a default option which may or may not be what you want vendors typically not used it's often actually where a lot of proprietary vendors that say build a new toolchain out of a lbm will use that to select your driver so say for example you've got a consultancy company hex or whatever and they would use that to put any particular driver of those things OS is your target operating system where non-technically means they're not off obviously things there would be things like say you might want to target free bsd net bsd or whatever or on x that's the final environment and will also determine the avi and the object path format that you choose so for example on a macro which typically the object path format is macro you can generate an L file by putting in the right triple that type of thing but of course you've got to be careful to choose the one the right one for your target one of the things that that thing does is choose what toolchain in place so think down a little bit the information details I think if you try and do any bits across a population you're stuck trying to work out what it does the fastest way to resolve what it's doing is to go look into the toolchain class and look at what it's doing it's sort of oh this must be documented somewhere and then no I couldn't find it well surely I can just document it and then I looked at it and went I don't know whether anyone could document this it's kind of a there's lots and lots of different things for example there might be things like oh I need to find this particular library oh let's try this particular directory because this is what it's like I'm going to use it put it in this directory here and it's just this big tree of things that might be developed by yourself but Jenny what happens when you call cloud what it will do is it will parse these options select what kind of driver it wants to go for and then it will invoke you know the various programs as sub-processed so for example cc1 is the actual seat and pilot ccc1as is the integrated consumption and lvusc is the in-concept program so if we say the architecture is there for target AR that will select the Linux tool change and then you try and do things in the Linux way so for example you've got things like dash i system where it finds your input parts there so that select the target so that's kind of where the list of the target trip is for these various things here and you can get at these options here with the yen sort of thing the dash being dash I've got it written down I don't know whether it's got a name it's the dash and then three what British people call hash symbols I think Americans call pattern symbols so someone a hand of mine now back at work actually called it the toilet brush operator yeah something like that I find that the easiest way to remember what it is so just a few of the things that I've mentioned there I've got to go through that again driver mode just kind of just tells you how the client will try add extra input files changes personality most of all on there if you wouldn't go to use a client CL if you do that it will try and emulate the command line options of Microsoft if you go to switch to outputting in wake at work Microsoft is the only consumer that's not of interest to you so the most important thing for us here is to use kind of plus plus if you're compiling C plus plus otherwise kind of mess out some of the header files and then you'll get things like you cannot find the mainstream type of things if you get that and you think it should just work you should try and use a client rather than a plus plus and manually say dash dash drive so one of the things that you might find is that as I said so what I wanted to do here is just go through some of the steps that you might want to go through for building a simple application targeting an AR64 so what I chose to do was to use compiler RT which is the runtime where it reads also where the sanitiser is implemented I'm going to use undefined behaviour sanitiser mostly because the memory sanitiser and the address sanitiser don't work with the incredibly user-mode emulator because they muck with age tables in very nasty ways the incredibly user-mode emulator is not really set up to do that kind of thing so I'm using the credit you've dashed out for all user-mode emulators just a simple way of testing it typically you're deployed to a device that's actually good so that on my shopping list is the tools that I'm going to need to do to make this a little bit so how do you actually get these components so if you don't want to you'll get the thing that you can scratch then the simplest way to do this is to go and download one of the LRBM releases if you're going to do this at the end where the sanitiser is you don't have to be careful because if you download the X86 release you'll get X86 binaries of Clang that can cross-compact with the AR64 but the sanitiser libraries will be X86 sanitiser libraries so you won't be able to run those on any AR64 copy if you download the AR64 release you'll have an AR64 Clang that you won't be able to run on any AR64 copy so you'll have to sort of combine the bits from 2 if you want to make a sort of full cross-compact version we'll also have to find C-Library and let it vary to have no seeds it's just two special ways to do it if you're on the next distribution support multi-arch then that's usually a very safe way to go I used the LRBM release which is kind of like a directory that has assist rooms with all of the libraries that you generally need plus the new hills I used that mostly to sort of just show the differences one of the if you're sort of in a production environment multi-arch might not be a stable way to get repeatable builds on different people's machines there's some people that download everything into one directory so they can be sure that they don't have problems so I won't go into all of that that's mostly saying here's where to download the NARO toolchain and how to install it what it is and that type of thing different GCC toolchains might have a slightly different layout than the NARO toolchains the things that I've written here you may need to experiment around with it so one of the things that I mentioned before about is the runtime libraries so typically in a compiler you've got various different locations of different queries so Clang has something called resorcerer and that's where people look for what you would call compiler specific libraries and I think I'm not an expert on this particular distinction but my understanding is it's kind of libraries that are include files that depend heavily on the implementation of the compiler of going this particular directory as opposed to saying a standard sort of issue directly and so I think you could print it out directly out but I don't think people change it to the command line options but if I remember you can pass in a develop a level command line option to do it but I wouldn't recommend that to someone so I could just mention there if you're going to bug in the compiler of these they need to be in this big long direction so here's the application I've got it out so basically all I've done is I've taken UBSign example application and I've just had an experience exception just to show that I control an exception it doesn't do anything useful but what we want is the UBSign sign the signature open code the exception is there mostly because if you don't get to there then we know that the exception handling has gone very well so there so here's what I did assuming everything was all put together okay I know it's going to be very difficult to read at the back it's probably something that's the best looked at offline but I just want to highlight some of the options that I've used so obviously let's sanitize let's sanitize it so we can find the ones that I found the hardest to get were the sysroute option and the gcc toolchain option now if the sysroute is all you need then what the sysroute option is is to say find your included files relative to this and libraries relative to this direction so I point this in my pre-downloaded in our own toolchain direction so why do I need gcc toolchain again and what this dash dash gcc toolchain is doing is kind of saying I want you to start in search for a valid gcc from this location because time has sort of various characteristics of trying to find the tools one of the things it can do is it can say I can't find a I can't find various things the sysroute that I'm looking for in this particular location I know I'll try and slash us up and sometimes it finds a program called LD and you can find the host linker then spits your ar64 by the regal so really what that gcc toolchain there it's sometimes necessary, sometimes not I tend to use it just to be absolutely sure it's going to pick up the gcc toolchain a quick comment important about that is that you should really use both gcc toolchain and sysroute because gcc has built time configuration and the sysroute can be in slightly different ways depending if it's there, be it in a bundle centres or anything like that so you should use both so yeah I just said that the bottom layer that's just using quenU and yes in principle the uv side can work on quenU using the user mode emulator so for those of you not familiar with the user mode emulator what it's doing is it's intersecting the system calls from the target and then emulating them from the host so that's why it can't handle msang then ksang so this next few slides will go through pretty quickly this is basically what would you do if I wanted to compile libc++ libc++ avi myself I think it's getting better and it's a moving target which is often why I think there's a lot less documentation about this than that actually it's a bit of a you kind of have to make sure that you know exactly what you want to build you need to know exactly what dependencies that you want, if you just say for example build libc++ you'll probably find it gets built against the new libgcc for example you'll actually have to go into this intelligent and you want it to build against the compiler and that's the same sort of thing you'll notice that there are various dependencies between the components so what I found the easiest way to do was to build all of these components standalone, and by standalone I don't mean to check out them all in one great big directory as Steve said, I'll be able to build instructions for them to return them for a minute but what I do is I build each component individually appointing the Cmake to the specific Cmake file rather than the sort of top level one that's separate to what we've worked out for so just some hints and tips that I sort of found out along the way so one of the interesting bits that I really wish I'd known about earlier is that the most client-file is called Client, and if I rename that to AR64-Linux-Commune-Client Client would automatically infer the target of AR64-Linux-Commune and I wouldn't have to put dash-dash-targeting more in the place so that's just a simple name of the file convention that you might find useful Simulink You can do any number of Simulinks and it will work That's so good to know There's a very recent I don't know whether this may be a listen to LRBM-M6 it will certainly be an LRBM-7 but they've just introduced something called the Confitfile where you can sort of say collect all of these cross-compilation options up into a Confitfile and it will just get automatically selected and there's a similar file naming convention where you can kind of name your Confitfile as a prefix but the exact deployment will automatically pick it up so you don't have to say or work the target Client-Dash-D is great for trying to debug what it's sending to the linux cap so if your step is failing used to dash-D option and you can see exactly what that's essentially for I've mentioned this is a toolchain and this is through yeah, as I mentioned earlier when using shared libraries you make sure the hosting target ones all fly up for CVEC cross-compilation I've found the most difficult targeting a linux platform that I could use quite a bit that had a link support that worked quite well so for example if you've got the cross-compilation linking the AR64 linux and AR64 linux that's actually pretty simple trying to do that when you've got to give the link a huge amount of extra flags so in the recent option there to CVEC CVEC Tri-Pile target you can stuff it globally and it won't do the link step which is really, really useful if you're just building a static library and you've never touched a link that's one way of basically getting past that and it's really, really interesting if you want to find out what various different system options are actually doing so conclusions can work well as a cross-compiler because of the number of different options that it's got you have to tell it to more than you would do to another CVEC there are defaults there I would say have the least resistance is to use the ones that are native to your system so if you're targeting linux it'll make you a lot easier if you can target the new versions of that point the bare metal driver I've got some back up slides of my experience trying to build some bare metal stuff but that was a whole new story that was worth the presentation so I haven't gone through that but of course there's something about that but that's all I have to say from there we've got the very small amount of questions they're two minutes I've got one question and one remark the question is you set up at the start to use a mostly or exclusively LLVM based toolchain with LLV and client so why does it still need the GNU toolchain so it uses in that particular example I didn't use any of the GNU tools but I used some of the GNU libraries so for example I used the GNU C library to the point and at the moment there isn't any plans to have a replacement for that point but if you're on a different architecture you might not have a linker in the LLVM program so you might have to use the GNU tools sometimes you set that anybody else? we've got one time when you cross combine the GNU for the latest LLVM version is there progress in compiling for example double double that's all we have for LLVM that's what you call this I'm sorry I haven't gone that early is anybody just without any recent developments in cost-efficient compiling much so I think would probably best wrap up for the next