Open source C/C++ embedded toolchains using LLVM
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61400 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023374 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Embedded systemChainComputing platformImage resolutionThread (computing)Standard deviationLibrary (computing)Binary fileInterface (computing)Computer programCompilation albumLatent heatComputer hardwareLinker (computing)Assembly languageSystem callSubsetFunction (mathematics)Multiplication signLevel (video gaming)DemosceneType theoryPhysical systemOperating systemQuicksortOperator (mathematics)MereologyMaxima and minimaSystem callChainLibrary (computing)Compilation albumReal-time operating systemImplementationWordStandard deviationDifferent (Kate Ryan album)Contrast (vision)Computer programmingLink (knot theory)Point (geometry)Semiconductor memoryComputing platformWindowSound effectSequelBoss CorporationComputer animation
02:24
Run time (program lifecycle phase)Configuration spaceImplementationCompilerChainExtension (kinesiology)Vector spaceEquivalence relationBranch (computer science)Pointer (computer programming)AuthenticationCompilerComputer configurationSystem programmingCode generationFunction (mathematics)KontrollflussData integrityKernel (computing)CodeElectronic signatureSystem callChainNatural numberPoint (geometry)Compilation albumImplementationStandard deviationRun time (program lifecycle phase)Moment (mathematics)Branch (computer science)Library (computing)Link (knot theory)Physical systemINTEGRALKernel (computing)Functional (mathematics)Maxima and minimaFiber bundleMathematical optimizationMultiplication signQuicksortWave packetType theoryCartesian coordinate systemSoftware bugAxiom of choiceSet (mathematics)CodeProcess (computing)Computer programmingBoom (sailing)Operating systemDifferent (Kate Ryan album)Structural loadControl flowBitObject (grammar)Computer architectureVector spaceBefehlsprozessorDefault (computer science)Crash (computing)1 (number)IntegerRange (statistics)Buffer overflowError messageComputer clusterElectronic signaturePointer (computer programming)Installation artLinker (computing)Scripting languageTable (information)Similarity (geometry)Electric generatorLetterpress printingFilm editingRight angleGame controllerScalable Coherent InterfaceSpeciesRoundness (object)CASE <Informatik>Greatest elementDirected graphGroup actionCuboidMereologyBridging (networking)PressureIntercept theoremArmClient (computing)Extension (kinesiology)Connectivity (graph theory)PlanningSign (mathematics)FunktionspunktmethodeCurvatureTerm (mathematics)Slide ruleMilitary baseComputer animation
08:16
Embedded systemLibrary (computing)System programmingScripting languageConfiguration spaceAssembly languageChainBuildingOpen sourceSoftwareArmArchitectureRun time (program lifecycle phase)Binary fileMultiplicationUsabilityComputer fileEmpennageComputer configurationoutputEquivalence relationDefault (computer science)Linker (computing)Connectivity (graph theory)Moment (mathematics)Equivalence relationQuicksortScripting languageOrder (biology)MicrocontrollerArmCompilation albumBuildingMereologyChainBitRun time (program lifecycle phase)ImplementationSystem callProjective planeLine (geometry)Library (computing)Type theoryInformationSampling (statistics)Default (computer science)Point (geometry)Computer fileCASE <Informatik>Range (statistics)UsabilityConfiguration spaceMultiplicationRevision controlDirection (geometry)Slide ruleFunction (mathematics)ScalabilitySource codePhysical systemCombinational logicMicroprocessorVideoconferencingSuite (music)Ocean currentMachine visionView (database)Lipschitz-StetigkeitBlock (periodic table)Link (knot theory)State of matterEmulatorExtension (kinesiology)Bit rateMultiplication signComputer programmingCodeOpen sourceHydraulic jumpIntelligent NetworkComputer animation
13:11
ChainParsingSocial classPersonal digital assistantProcess (computing)Group actionCompilerAssembly languageLink (knot theory)QuicksortOnline helpPoint (geometry)Physical systemSoftware developerOperating systemEmailComputer fileComputer architectureObject (grammar)Default (computer science)Generic programmingType theoryIntegrated development environmentBitLevel (video gaming)Key (cryptography)OctahedronSpacetimeMatching (graph theory)Link (knot theory)TheoryState of matterMultiplicationArmMoment (mathematics)Compilation albumComputer animation
15:05
MultiplicationComputer configurationConfiguration spaceDirectory serviceMechanism designDifferent (Kate Ryan album)InformationChainFeedbackCodeRun time (program lifecycle phase)Scripting languageLinker (computing)UsabilityAttribute grammarLink (knot theory)Mathematical analysisSystem programmingModule (mathematics)Read-only memoryMereologyIntelligent NetworkIdeal (ethics)Point (geometry)QuicksortRun time (program lifecycle phase)MultiplicationConfiguration spacePatch (Unix)Computer configurationChainLink (knot theory)Boundary value problemSheaf (mathematics)Line (geometry)Lattice (order)Function (mathematics)Presentation of a groupSemiconductor memoryCompilation albumArmSoftware developerMoment (mathematics)Form (programming)BenchmarkSocial classType theoryBitRight anglePlanningMultiplication signComputer hardwareScripting languageCodePosition operatorTowerState of matterSoftware testingCondition numberCASE <Informatik>Client (computing)Linker (computing)YouTubeSurjective functionData structureDirectory serviceLibrary (computing)MappingComputer fileParsingBefehlsprozessorDifferent (Kate Ryan album)Attribute grammarRobotBuildingBranch (computer science)Computer animation
19:19
Scripting languageLinker (computing)UsabilityRun time (program lifecycle phase)CodeCompilerAttribute grammarLink (knot theory)Mathematical analysisChainSystem programmingRead-only memoryModule (mathematics)Latent heatInformation securityExtension (kinesiology)SynchronizationTable (information)RoundingSoftware developerArmSoftwareSoftware bugMultiplication signPhysical systemPatch (Unix)Type theoryState observerSystem callChainQuicksortRoundness (object)Software developerPoint (geometry)Extension (kinesiology)OvalInformation security1 (number)ArmCodeComplex (psychology)AreaEmbedded systemTable (information)Link (knot theory)BitAnalogySpeech synthesisTraffic reportingProof theoryState of matterLattice (order)Computer animation
21:36
ChainMacro (computer science)Direction (geometry)Assembly languageAsynchronous Transfer ModeINTEGRALProjective planePlanningMathematicsGoodness of fitKernel (computing)Front and back endsExtension (kinesiology)Virtual machineEndliche ModelltheoriePatch (Unix)Entire functionRun time (program lifecycle phase)CodeCompilation albumBitMereologyElectric generatorFreewareQuicksortType theoryPhysical systemDerivation (linguistics)Arithmetic meanLibrary (computing)Semiconductor memoryLine (geometry)State of matterCovering space2 (number)Chemical equationMultiplication signSampling (statistics)AdditionLink (knot theory)Term (mathematics)Process (computing)MassComputer animation
26:28
Link (knot theory)Assembly languagePoint (geometry)QuicksortInformationLinker (computing)Type theoryDifferent (Kate Ryan album)Electronic mailing listString (computer science)EmailMultiplication signPhysical systemComputer fileBuildingAutomationCategory of beingBinary fileElectric generatorExtension (kinesiology)Computer programmingScripting languageOpen sourceCartesian coordinate systemVideo gameCompilation albumProcess (computing)CASE <Informatik>Right angleCoordinate systemPoint cloudLevel (video gaming)Latent heatStatement (computer science)LengthSheaf (mathematics)CausalityArmPOKEBitSpacetimeProjective planeSoftware developerRoundness (object)NumberField (computer science)State of matterZirkulation <Strömungsmechanik>DistanceComputer configurationSymbol tableDisk read-and-write headComputer animation
32:29
Program flowchart
Transcript: English(auto-generated)
00:05
Next up, we have Peter Smith who will talk about using LLVM to create embedded toolchains. Hello, my name is Peter and thank you all very much for staying up so late. It's almost bedtime. So yes, I'll be here to talk about embedded toolchains using LLVM.
00:23
So the first thing I want to clarify is what do I actually mean by an embedded toolchain? Now, some of the people here earlier on were talking about sanitizers, and we mentioned Yocto and embedded Linux. That's way too high level. This is basically for bare-metal embedded systems.
00:40
So yeah, so typical, for those of you who already know this, I'm sorry, but for those of you who aren't necessarily familiar about what some of the differences are, so typically when you're developing on say, Linux or Mac or Windows, whatever, you're developing with the knowledge of an operating system. So when you implement your C library, you already know you can use system calls. You know, if you want to get some more memory,
01:01
you ask the operating system, that type of thing. So by contrast on the embedded system, you don't have an operating system, you can ask for memory. So you basically have to roll part of that into the C library, that type of thing. So also when you're actually programming, you're programming on the device, you're actually running the program on embedded systems, you're cross-compiling. That is one thing that is likely shared
01:21
with Yocto and embedded Linux, because quite often you'll cross-compile for speed on that one there. Typically you'll be static linking only because your RTOS probably doesn't have a dynamic link at that particular point. And your RTOS might actually just be a library that you link into your program, that type of thing. So yeah, so platform, if you're on the Linux,
01:42
you might be using glibc, that type of thing, and that will be platform. And then you just use, when you have a tool chain, you might just need to provide a compiler and everything's there for you. Embedded systems, everything's just, you have to do everything all yourself. I will mention one word there, freestanding. So there is a definition in the C plus standard
02:00
of what freestanding means. It's a little loose. It kind of says, this is basically what the minimum you have to supply, but that's practically useless unless you want to write a full C++ implementation yourself. So in effect, what happens is that most embedded C libraries tend to roll half of an operating system into themselves, or at least basically our basic minimum from there.
02:22
So that's what we're sort of talking about by an embedded tool chain. Okay, so this is the thing, we already have embedded tool chains. Why do we need LLVM, essentially, at this particular point? So this is some of the reasons why you might actually want to use LLVM over, say, something like GCC. So first of all, Clang is kind of a natural
02:40
cross compiler, so you don't actually have to say, gather GCC for ARM, GCC for S5, GCC for AL64, you just have one Clang. Now that is quite useful if you're a team where you don't want to use different compilers, different installations. That's, I guess, more administrative more than anything, but it can be a benefit on some places.
03:00
So code generation can also be more mature, and I will say, be safe in fairness, sometimes less mature than GCC, for example. So my, it's obviously for somebody who works for ARM, all my examples are from ARM, just because that's what I know, but I'm sure there are similar sort of things on other architectures as well. So an example here, V8.1n,
03:21
which is one of ARM's most recent, sort of modern CPUs for embedded systems, it's got a vector extension, and basically Clang has got better support for auto-vectorization for this than GCC, just simply because the work was done earlier, that type of thing. But that's just one of the examples why if you've got that particular target,
03:41
you might want to use that, whereas if you've got a different target, GCC might be better at the moment. Other thing is taking advantage of some of the tooling that Clang provides. So I'm gonna go into, in the next few slides, how you might be able to use some of the sanitizers. I know we kind of said in the earlier bit this morning that we were talking particularly about MSan and ASan,
04:01
that type of thing, and those typically have quite a high runtime component, but there are sanitizers that you can use without that, and I'll just go through a few of those here. And finally, you've got diversity of implementation. Running more compilers is almost always good. Compilers find different sets of bugs, and sometimes programs find different sets of compil... Sorry?
04:20
Yeah. I was working recently on safety critical application for train. Yeah. So you actually have to implement several processes doing different things. So having two different compilers is a good thing in that application. Yes, definitely, yes. And certainly you can, different programs find different compiler bugs as well, that sort of thing. So yeah. Okay.
04:40
So do you think sort of sanitizer embedded systems, so we kind of run through some of this earlier on today. So the main restriction of sanitizers is that it's not actually the code generation, it's actually the runtimes. So if you look at the runtime for ASan, it's basically using a dynamic shared object to intercept the C library. It's got all sorts of bits
05:01
that sort of kind of are operating system dependent, but of course in embedded, you don't have an operating system. So it's very hard as a tool chain vendor to provide a kind of bare metal thing that doesn't depend on one very specific example. But some of the sanitizers have a very minimal runtime. And some of these things you can use here. So I'm just gonna go through some of these right now.
05:22
So the first one to use is the undefined behavior sanitizer. So by default, that does have a runtime. But all that runtime effectively doing is pretty printing a nice error. But if you don't care about pretty printing a nice error, you might not even have a printer. So at this particular case, then you can just say, okay, well, if there's undefined behavior in my program,
05:43
and someone's trying to attack me, maybe that's a bad thing. So maybe I just want to abort, say, for example, if I've got an out of range runtime. This particular example is just using a very standard integer overflow detection. And basically look on there, all it's really doing is just saying,
06:00
check for overflow, if I overflow, branch to an undefined instruction that just happens to cause an abort on the processor, that type of thing. So yes, crash your program. There's also a minimal runtime. So there is a default implementation to the minimal runtime in compiler RT. You can't use that directly on an embedded system, but you can basically write your own.
06:20
So instead of actually calling, well, going branching to an undefined instruction, it just calls a user defined function. And you can basically make that do whatever you want. There are ones for log and continue, and there's ones for log and terminate, that type of thing. But basically the choice is yours. But those functions have got extremely trivial implementations that you can make work for an embedded system.
06:43
Okay. Next one here is the kernel control flow integrity. And it's called KFCI, and I keep calling it KFC. Oh, I've even got this the right way around. It's actually, I think I've even got it wrong on the slide, which is embarrassing. I should actually be KCFI at that particular point.
07:00
So there is a control flow sanitizer that can work with embedded systems right now. That's the sort of the full fat, I call it sanitizer. But that requires link time optimization. So the advantage of the kernel control flow integrity sanitizer is it doesn't need LTO, which makes, which,
07:21
if anyone's tried to use LTO in embedded systems, it works until you've got a linker script. Certainly you want a linker script that depends on placing things in different places. So yeah, so here's just a very trivial example of something that's just calling a floating point. And this just shows some of the code that's generated. So what we essentially have is this function pointer has a type and you can basically make that
07:42
into a signature. So what happens is we prefix at the top of the function with the signature, and then we basically load when we're sort of saying, oh, let's load from this arbitrary function pointer. Well, let's check its signature and then we'll check to see if it matches what we want and if it doesn't, boom.
08:01
So this doesn't, as far as I know, work on C++ V tables at the moment. As obviously this was implemented for the Linux kernel, so they don't care about C++. But if you're using C with function pointers, this is a way, a relatively low cost way to get control flow integrity checking. So this is just some of the things that the components of an embedded tool chain,
08:21
I'm kind of jumping around here at the moment. So these are sort of things you would expect in a GCC embedded tool chain. And as you can see, Clang's actually, well, LLVM project, we've got pretty much all that we need in one place. We're only really missing a C library at the moment. I won't go through each individual thing in those titles,
08:42
but you've got Clang, the compiler, you've got LLD, the linker, you've got implementations of objdump, read-elf, you've got implementations of the C++ runtime library. Yes, say, what we're missing is a C library. So technically GCC doesn't have a C library either,
09:00
but there are hooks in the build system to basically build new lib in sort of multi-lib configurations at that point. LLVM is developing a C library. I would say at the moment, currently it's sort of focused on what you'd probably call desktop use cases, but they are planning to have sort of scalable implementation. So I think the end goal is that
09:20
it will be able to cope with embedded systems, but I expect that to be some years down the line at the moment. So how would you actually assemble one of these buildings? Well, basically assemble an LLVM tool chain from the LLVM project. And the honest answer is it's not as easy as it could be. Certainly when you're building a hosted tool chain, it's just, you know, it's fairly easy.
09:41
You just go to LLVM, C, mate, ninja, done. So actually building the tools is not difficult because they're all cross-compilers. They're just all part of the default build. So if you want to get all the tools, very, very simple. Building the runtimes is a bit more difficult because you've got to cross-compile the runtimes, and you've got to do them in a particular order.
10:01
Not all of them build in all of the things. So one of the big problems, if you say, try and buy a compiler, sorry, if you try and compile compiler RT, it'll fail because you've not got all of the, you know, it's kind of, if you try, it will end up building the sanitizers and the sanitizers obviously have got dependencies on POSIX operating systems, which of course won't work. But you can say, for example, build the built-ins,
10:22
which are kind of like the libgcc equivalent. So what we've done at Arm is to put together an embedded tool chain for Cortex-M, which is the sort of Arm's microcontroller range. And this is essentially a set of build scripts. It's all open source. And we're using the PicoLib C at the moment as our C library.
10:42
We did start with NewLib, but we sort of moved on to PicoLib at that point. But you can make it work with NewLib if you want to. So yeah, so we've got, it's primarily just build scripts. It's not like got an LLVM project embedded on that. It will just go fetch LLVM from the actual source code.
11:01
And yes, it's got a few samples for building some programs, that type of thing. So as I say, it's by Arm, for Arm, but I'm sure if anybody wanted to apply it to a different microprocessor, they pretty much could, because it's essentially just a bit of CMake and that you can adapt.
11:21
So what's the usability of an LLVM tool chain like next to say the GNU embedded tool chain, that type of thing? So one of the main things we're missing at the moment is multi-lib support. Now there are some multi-lib support for certain targets. So for example, I think there are some RISC-V multi-libs that are already in the bare metal driver,
11:40
but that's not the case for Arm at the moment. I'll go on to what we're doing about that in a few slides time. Clang also doesn't have a direct equivalent of GCC specs files. So specs files are basically just fragments of command line, but they're not just raw command lines. They have got some intelligence and they can talk to each other and override sort of defaults.
12:02
So as an example here, that nano.specs and rdimon.specs, that says, give me new lib nano, which is the really small version of new lib and rdimon is the semi-hosted version, which is easier to run on emulators, that type of thing. So for the LLVM embedded tool chain, we basically, because we don't have the information
12:21
for the specs file to say, ah, someone else has someone added this other specs file, so I'm gonna modify my behaviors. We have to basically have multiple config files that just blow up for all of the possible combinations. So as you see there, we've got an Arm v6n, which ideally would be handled by multi-lib
12:40
in DMD semi-host version. And yeah, there's just more configuration files than you really ought to have. And I would say there's probably a small, well, there's a long tail of small incompatibilities. You might find that LLD doesn't do orphan placement exactly the same way as GNU-LD does, that type of thing.
13:01
But normally these sort of small incompatibilities, you can kind of code around it. There's normally a ways you can make it work. So that's what we found so far anyway. Okay, so this is just, again, another jumping around, just showing you how Clang might do some of this sort of stuff. So if any of you have played around with Clang drivers,
13:21
whenever you give them the target triple, so normally if you're using Clang on your Linux, your target triple is native, I guess, at this particular point, or you're using the default triple that's there. But if you're doing cross-compilation, you have to give it a sort of architecture environment.
13:40
So you've got the Linux-GNU there. So this is actually one, if you were targeting something like the Octo, that type of thing. And that Clang driver will then tell you where all of your header files are, what your target features are. So it's like a much low level using sort of private command line options, that particular one. So for what we find for embedded systems
14:03
is that Clang has added something, well, probably a few years ago, but it's sort of only recently sort of getting a bit more development onto it. In particular, the multi-lib support for RISC-V came in fairly recently. And that's when you have a target that the bare metal handles.
14:22
So far, that's only RME AR64 and RISC-V at the moment, but this, in theory, could be added for any other target, that type of thing. If you happen to be doing bare metal development on an x86 and you don't match, say, a Linux operating system or BSD or whatever, you end up getting forwarded to the generic GCC driver,
14:41
which basically throws everything at GCC, which generally knows what to do about things. So as long as you've got a GCC tool chain, if you give it an object file to GCC, GCC will say, oh, I'll just fire that at the linker, that type of thing. So it will work itself out. Okay, yeah, so I've just basically repeated what I've just said there.
15:01
It will default to the LLVM tools at that particular point. So as for the last part of the talk, I just want to go to some of the ongoing work that's happening in Clang and some of the community involvement that's going on here. So one of the first and probably the major bit of work that we're doing at the moment is what I'm gonna call data-driven multi-lib at the moment.
15:21
So currently, multi-lib support in Clang is hard-coded. It's basically a C++ class where you basically describe what the multi-lib will do for that. Now, that works pretty well if you're doing things like 32 or 64-bit x86 in, say, Debian or Red Hat, because the structures are well-known
15:42
at that particular point and they are stable, whereas there's no way every possible embedded toolchain with every possible library variant that you might want to do could get that hard-coded in upstream Clang. So typically, what you find is that every toolchain based on LLVM has its own downstream patch if it wants to support multi-lib.
16:02
So GCC allows you to set this up at configure time and the GCC way basically maps command-line options onto directories. So for Clang, we can do a bit better because the Clang driver has a bit more scope to, say, do things like target parser and find out more about what the CPU can do.
16:23
So at the moment, we're kind of proposing that you kind of have a stacked tower of multi-libs where you can kind of, almost like a Docker container file where you get each sort of can override the next so that you can basically describe what your multi-lib configuration is and then Clang will be able
16:40
to take this configuration file. So it will basically allow people to have multi-lib toolchains without having to hard-code them in downstream patches, that type of thing. So this is still in active development. There's an RFC that went up probably a few weeks ago. Recently, there's some links to the patches and that sort of thing.
17:01
So please do, if you're interested in data-driven multi-lib and how it develops, please do comment on those patches and the RFC. Okay. So future work. So we'd ideally like to get some upstream build bots for some of the compiler RT runtimes. So whilst there are build bots for AR64 and ARM Linux,
17:24
we haven't got build bots for say the built-ins for say the v6m, v7m, the sort of the very low-level embedded sort of targets and we think that would be good to, well, obviously more build bots the better, I think at that particular point. There is some work going on at TI
17:40
and that link to YouTube is to a presentation from the, at the last LLVM developer meeting, basically adding attributes from the linker script so that you can tell, you can basically say things like, this section must go in this place, this output section.
18:01
This one must go in this other one. Please do not cross module inline across these boundaries because these things might not be in memory at the same time, that type of thing. So, and also I need this section to have this particular name so please don't give it a different name or merge it, that type of thing. So that should be able to make LTO much more usable with linker scripts and what we tend to find with Clang
18:21
is that if you get it right, LTO is very aggressive at removing code that's not needed. So that's actually very good for code size if you can make it work. Certainly we've seen for benchmarks, LTO is great but then we say to customers, hey, use LTO and it goes, ah, but we can't because of the linker script, that type of thing.
18:41
Next one is not strictly embedded but it is very important for the safety critical industry which often is by definition embedded because you're controlling some kind of hardware and this is something called MCDC code coverage and that is kind of a special form of code coverage
19:01
where you're kind of, if you can imagine something like if and then A, B, C, D, E and E, it's a way of sort of deriving test cases so it's not quite exhaustive but it covers more than just did this branch go this way or this way. It's like did it go this way because this condition held, that type of thing.
19:21
Hopefully that's not gonna show up too much there. And yeah, so there's a patch in for generating that in the code coverage thing. And obviously, LLVM libc developing and we would like that to support embedded systems. Okay, I'll skip through this very quickly. There's some patches up for big-endian support if anyone actually uses big-endian, I don't know.
19:41
I'll be rude there. There's an armed person in the way, almost all arms a little-endian. And then there's the Cortex-M security extensions which are, you know, that's very useful if you're trying to sort of have secure state, non-secure state so that supports an LLD. Again, if anyone wants to comment on those patches, please do, okay. Okay, so finally, if you do want to contribute to this,
20:04
and this is not just as a developer, we're perfectly happy to have contributions from users as well, or just in some ways just telling us what's important. So Clang has pretty much come out of what I call the hosted community. You know, it's generally, at least as now,
20:21
I would say there's a lot fewer people in the embedded systems area than there is on GCC. So if you, you know, there are certain features that are useful in embedded tool chains, but not necessarily in, say, hosted tool chains. So just telling the community that you need these features is often helpful, because quite often it will say, why do we need all this complexity for this thing?
20:41
No one's gonna use it. And it's like, well, and you can only get, people will only use the features if they're there, but then you can't get them in, you know, chicken and egg situation there. So yeah, so there is a full weekly call that goes on, unfortunately at a time slot that's not great for Europeans, but this is the only sort of time slot
21:00
you can kind of get across US and Europe together at that particular point. So that's probably about, I'd say about 20 people turn up and that's really just about the various people who are working on embedded systems and if they want to sort of highlight patches that want to be reviewed, discuss, you know, new features. Last time we were talking about how we might improve
21:23
LLDs and observability of diagnostics, that type of thing. Obviously, bug reports welcome those links and obviously if you attend the developer meetings, there's often a round table on embed systems at that point. And with that, that's my last slide. So hopefully you've got a few minutes for questions.
21:41
I'd like to understand something. I know of some people who say that they're using LLVM for embedded already. Does this mean that they're using the other definition of embedded? So there's two, well, you can do it.
22:03
There'll be three ways they can do it. One of them is they're kind of using an LLVM based tool chain from a vendor. So that vendor will have done all of that packaging up or it will be a, like for example, ARM will sell you a commercial tool chain that is a derivative of Clang, that type of thing.
22:21
That's one way of doing it, that sort of thing. Or they might be using embedded Linux, that type of thing. Yeah, the question was, sorry, I've been holding up a picture all day saying please repeat the question, I didn't. And so the question was that some people say they're already using LLVM. Does that mean they were using hosted system or not? Yes, the first, sorry, the guy at the back there.
22:42
Yes, so one of the things I noticed is LLVM ships its own assembler. Yeah. And we've noticed for some of the projects that they have trouble with some of the newer assembler backloads. So we have to use, have to fall back to the two changes for assembly targets. Is there some plans for work on this? Ah, so it was to, so with the latest LLVM I know,
23:06
sorry, sorry, repeat the question, yeah. So the question was the LLVM has an integrated assembly, GNU has GNU-AS, and there are some directives or macro support that might not, that might be in the GNU assembler but not LLVM.
23:21
So I think it's generally done on demand. So there was a big effort to get the Linux kernel compiled with Clang, and that added quite a lot of features that were basically needed for the Linux kernel. So the best thing to do is have a really important project that a big company wants to get compiled with the integrated assembler.
23:42
Yes, and yes, yes, that is a very good way of doing it. As macros were in the Linux kernel and they asked us to support and say, no, screw this, this kernel changed away from macros. And they changed away from macros. Yeah, but there certainly was support, I think there is a directive where you can switch
24:00
the GNU assembler into advanced macro mode or something like that, or I can't remember. Are there he knows Jesus? No, that's not, that's an inline assembly thing. There is an, yes, there is a highness GNU extensions option, but that's, yeah, okay. But no, there was a patch that probably landed a few years ago, so depending on how long ago you tried,
24:22
then there was some support done for more macros, but whether it's got all of it or not, I don't know. No, I actually don't, I don't know. Right, again, so you may find that someone has already fixed that already. Okay, yes, thank you. Yeah, so my question is about like we, for example,
24:42
tried to deploy machine learning models on tiny bare metal devices. Yeah. And there we are also looking into, for example, TVM as a tool chain, but also MLIR now, like the EV project from Google. And they're basically what they do is they use this entire tool chain and then they use the MHC dialect, for example, in EV to emit C code again.
25:02
Okay. To then put it into an embedded tool chain to actually do the final compilation step. Do you think that there is, or what is basically needed to omit this last, going back to C, or is this a good idea or another? Oh, well, I mean, I suppose,
25:21
I'm just trying to think how, not very familiar, the question was about people deploying machine learning models on small devices, and they're currently outputting to a C backend and then recompiling that C backend. And do I think this is a good idea or not?
25:41
I mean, I guess the C backends are often, how do I get this up and running as quickly as possible? I do know that there are, I guess, machine learning compilers that have got, I guess, code generation out. I mean, I guess if you're using LLVM itself, it's probably not too difficult to just lower to LLVM
26:03
and you then get the code generation for free. I guess the bit that you might not get is have you got all of the runtime and intrinsics that you might have that the C compiler might insert, but I don't, you might find someone else in this way. So maybe just in addition, it does not compile the whole machine learning models to C,
26:21
so they are still a static library linked in which is generated via LLVM. It's just some parts around, so it's not that there is a pure C in the end. That's not done in the approach. Yes, sir, yes? I was one of those unfortunate users of big-end arm.
26:42
We were running several compilers in the safety critical application. Everyone had a problem with one thing, and that's the linker. We're trying to generate a header. And the linker, you can't insert the text string in the linker. It's very difficult to insert static data. We want to insert information about
27:02
how large is the section. That was basically impossible to do with the linker. How does LLVM handle such things? With great difficulty, I think. There isn't really a, there isn't, I think the, yeah, I think Christoph has nailed it in that
27:23
what I would probably do myself is reserve some space in the binary, name a section out of it, and then use objdump to poke it, poke it in at that particular point, yeah. No, but- Have you seen my problem? No, yes. I mean, there are some- I'm putting a string in the link command file.
27:41
Well, it's a bit, well, it's a bit more difficult. I think the linker needs to know the length. I mean, I suppose you could do it with horrifying things. You could use data statements in a linker script, but that sounds a bit, it's really what you would want it, you really- I want them. Yes, I really, I think, yeah, cause you get a number, but really, yeah, I suppose, yeah.
28:02
Find the extension request of the linker scripts, screen. I can specify the size of the section to start with, then I know the size. Yeah, I think we do have the problem with things like build ID, I think at that particular point where you're generating the build ID string, which it needs to know everything all at once, but yeah, unfortunately there's nothing
28:21
in the LLD linker that's different. I think someone should try to generate the header for a binary containing the interesting information, then you quickly realize all the problems. Oh, yeah, sure. But no assembler has the ink bin. Yes, the assembler does have ink bin, but I think the idea is for the header, you want the linker to generate something
28:42
based on the properties of something, but. You want to generate the information about the link time, not when you assembled it two weeks ago. You can assemble just before the link step, assemble something that's generated. You cannot even .o file and then link that in
29:00
using the link script, you can. I know there are workarounds, but a good workaround would have to have a good linker. Yeah, I mean, I think, I mean, a lot of the times with linkers, it's the, because one of the perennial things you get asked is, how do I embed some kind of custom checksum that I've written at link time, that type of thing? And it's just which one, and do you then have a linker Python script extension
29:22
or plugin that, it just tends to build. When you're running an application that added a checksum afterwards, that's also something that should be supported in linker. And it could be done, just say, run this application afterwards on this section, something like that. So it's, I mean, I guess, yeah, I mean,
29:46
I guess it's, I mean, to paraphrase, I guess it's the tools are supposed to make user's life easier, I suppose, at that particular point. So if it's a common enough thing to do, then it should be, they should be able to find a way of doing it. And if this is security, then you don't want to generate the checksum in one process
30:02
and then use it in the other process. You want to use all in one, because I know who generated this. It didn't come from outside. We actually have to have two different programs. Yeah, so I better go for, yeah.
30:25
Essentially, like, you're talking about communicating between the cloud stage and the link stage and introducing dependencies to do what the cloud was, and then you have to link with it after that. Right. And now, like, in a dependency specification for that, so the build systems could actually use it
30:41
and spare the users who have to deal with all this crap. Nice. I mean, well, I think that the big, I'd say it's mostly a, what I would call almost a coordination problem between getting the right people on board at that particular point, and it's,
31:01
so it's quite, sorry, yes. Okay, so the question was about, is anybody working on build systems and things that they will be able to communicate the, of the linker to be able to communicate to the build system and automate things like the checksum sort of handling and that type of thing. I mean, I think the major difficulty is just,
31:24
LLVM's an open source project, and there's often, as soon as you open something like that up, it ends up in lots and lots of discussions about what the right way, and you can easily find a way that works for one, the small number of people, but completely doesn't work for someone else. So it's one of those, it first of all needs someone
31:41
brave enough to actually try it rather than just implementing it downstream. So I think it's, what it really needs in this case is, because this is sort of things that, this is not, it really needs people to go on the LLVM mailing list and say, yes, we really need this, because typically this sort of thing is to silent people who say, oh, this stuff's all rubbish,
32:01
but we don't, as developers, we don't get to hear about it, or at least we don't get to hear it, hear about it loud enough for the people who pay our wages to say, go and work on it. And, yeah, right, yeah. Okay, I probably ought to hold it there
32:21
to let everyone go, I think, at that point. But thank you very much for staying at the LLVM. Thank you.