 Good afternoon everybody. Thanks for attending the last session. I'm going to present a new project. I call it only BC and you can access the presentation including the source code in the URL. The URL is, I think it's quite easy to remember, it's just the same as the library name. I'm Jun Huang and my experience was, I was a contributor of AOSP since 2010. I already contribute for more than 50 contributions to AOSP. Also I'm co-founder and developer of LSD which is the library desktop environment. Besides that, I was the developer of the Naro working on Android platform. My employee history including MediaTek and IQQ. So I'm going to discuss about based on my experience, I would like to talk about the idea to reuse the Android for ordinary linear space products. And so I will discuss about the C-Library Toolchain Optimization and Confluent Group for a long time. Before this session, you can refer the related talks including Android Builder Summit. The LLB and Linux, this one is very interesting. And you can refer to Torbath and the memory allocation including this afternoon K Configure. So there are four parts in my talk. The first one is we are going to analyze how we can benefit from Android. Then we can make a new project, I call it old EBC. So the project goal is to be configurable. And then we apply some optimization techniques. The last one is an action item which is something I didn't complete yet. So the first one I will talk about how can we benefit from the existing Android infrastructure. Including Bionic, LibreC, DynamoLink and some debugging facilities. So you already know Android is not linear. But our plan is to take something useful back to embedded linear. Yesterday, Roy had an excellent talk. He mentioned that Debian is the new long batch and Bionic LibreC is just a long time to to excuse the new long batch. So Bionic is very interesting because Google already modified heavily to fit its requirement. So why should we choose Bionic as the base for our new project? I think the first one is very important, the license. So if you compare some existing open source projects, GDBC is GPO, microcontroller LibreC is LGPO, Dial LibreC is GPO, Muscle LibreC is MIT. That's good. But if you check the implementation, you can see if you compare some target like the lattice on MIPS and Intel OTAN. You can see GDBC does optimization pretty well and microcontroller LibreC does some simple optimization. But Dial LibreC does nothing for optimization. Muscle LibreC only does the simple Intel architecture optimization, mainly in Mathematica. You can notice that Bionic has better API coverage by versions. And it already can run some complex applications like LibreOffice and FIFAS browser already. So I think the Bionic LibreC is getting better. Also, you can mention that Bionic LibreC already merged some contribution from several SOC vendors like Qualcomm, like TI, NVIDIA, STL, even Naro. The upstreaming is, I mean the progress of upstreaming is always slow. But you can see it's a potential benefit. So if we can propose a new open source project to merge this effort, that should be very interesting. So the goal of LibreC is pretty straightforward. So first to create small, fast and standard compliant implementation of C-Library. Also, we offer the configurable some option to configure the implementations. So you can configure from very small implementation to smartphone-like devices. Also, we pick out all the system components, for example, benchmarking validation or even prelinker from Android as the base. We can merge some security enhancement or fixes from other open source projects like NetBSD, FreeBSD, even some CVE fixes. You might know from several vendors like STL, NVIDIA, TI, and other SOC vendors, they all have git repository or other open source repository. So it is very interesting if we can introduce all the enhancement into the single source tree. So let's review the programming model first. As soon as there is a hardware program, so you can see you use a compiler to generate the EF image file, and then program loader load it to memory. So you can see some sections like state of BSS data and the text. So for build mental model, it looks like a broader or some simple non-oil environment, so you're just straightforward. But for some environment like Android, it's multi-threaded, so you can see it's going to be more complex. And if you compare Linux and Android, you will find that the basic component, I mean the kernel and the library, are almost the same. And there are just some minor differences. So our idea is we try to move something interesting, something useful back to embeddedness, so from the right side to the left side. So let's review Bionic libc. It is a small C-diver implementation, which is a mixture of NetBSD and FreeBSD. FreeBSD, the inclusion of FreeBSD is pretty new. It is about last year in AOSP master branch, especially for the libn implementation. Bionic libc is majorly in BSD license, which has partially portless compliance, not compatible to GDC, and there is no system 5 IPC support, because Android engineers think that they are superior, I mean there is a replacement called Bind IPC. For AOSP master branch, there are mainly three targets. One is with stumble support, and Intel X86 and MIPS target. In the past, there is even a super-h architecture support, but the architecture support was removed about two years ago. Also Bionic libc has fast pith-ray implementation based on few tests. So if you compare the full-point, you can see GDC, micro-control libc and Bionic, if we compare some older versions, you can see quite a large difference. So GDC is one megabyte, but Bionic libc is only 243. Bionic libc has some limitations, so you can see there is no complete wide critical support, and there is no full C++ section support, and there is no fully C++ STL, and no fully POSIS support. If you check the source tree, you will notice that there is a very important description about memory map. So before Android 4.0, the memory map is fixed, so you can see the linker and the native library along with the Java occasions. They all have fixed address. But after Ice Cream Sandwich, which is Android version 4.0, the memory map is already changed. So let's check the changes. Since Android 4.0 Ice Cream Sandwich, there is a new mechanism called AOR, which stands for address-based layout randomization. So it advances security enhancement, which is known to protect system and third party application from attacks. Also, since Android 4.1, there is a new mechanism, PIE support. You can notice that the original prelinker, EF prelinker was removed since Android 4.0, because the memory layout is totally changed. Since Android 4.1, there is an interesting feature called address sanitizer. Adress sanitizer is a special memory long-time memory checker. So we can compare if it's wagering. So you can see it can perform some checking. For example, hip-out bound check, stake-out bound check. And the OHA is very, very low compared to wagering. So you can enable the feature. You can enable the feature and check some output like this. If you have a buggy program like this, it's buggy because there's free. So the system will dump this useful information. So you only have to add one line, this line in file android.mk and then address sanitizer will be automatic enabled. So this is a reference output. So you can see there is a buggy program. It's our range memory access. So you can see the memory checker detects the problem for the address. Also, we can check the share library implementation in Android. The older Android dynamic has some problem which limits the number of share library to 128. And since last year, finally, there is a change which allows dynamic allocation. So you can see Android Bionic has long history if we count it from Android team. So it's from 2005. So seven years past, the diamond link already has no such restriction. This is very interesting. And you can see from other open source project like Mozilla or LibreOffice, how can they overcome such problem? They use extra HEC copy of Bionic library. So if you download a Firefox browser in your mobile phone, there are two dynamic link at the same time. It's ridiculous, but it is a problem. So you can see from the above description, Bionic has some good part like this. This is good. And Bionic has some short part like this. And you can see about C++ integration. There are already several solutions. So if you check the NDK, you can see the comparison. By default, there is no C++. I mean, there is no fully C++ port. But you can use some extra packages like STL port. So STL port does not support C++ exception, but support C++ RTTI, which stands for long-time identification in current Android configuration. Also, you can use GANU-STL packaging, which supports both C++ exception and RTTI. To simplify the porting effort, we only provide, only the C++ only provides STL port. And it depends on the wide correct support in C library. Also, there is an interesting component in Android called Debuggedy, which is embedded-specific cache candler. So it can correct the crash data in certain files. And also, in addition, Debuggedy can also facilitate committing Debuggedy to a dyeing process. So you can correct the information before a process being dyeing. And it is a BISD license. How it works? Basically, Debuggedy has a crash handler demon. Also, it has a default signal handler to each process, which handles any signal that is generally called, I mean, the cooldown. So you can think about the interaction between Diamond Linker and Debuggedy. So once the default signal handler is registered, when application is going to dye, so you can catch the information. So the signal handler captures the information and contact Debuggedy. So Debuggedy can use its built-in on-stack unwinder to generate backtracks. This is very important for Android tracing, because you have to couple with both Java and the native long time. So usually C and C++. It's a common technique that if you want to trace running Java problem, you can trigger a signal to access Debuggedy to capture the backtracks. And you can even ask GDB to attach. And the Linalo compiler, sorry, Linalo Toolchain Working Group improved Debuggedy two years ago. So the improved one can generate more specific backtracks information and even has better integration with GDB. Timber of Sony improved Debuggedy. So he took the code base from Android and applied to ordinary Linux. So he created a new project called Crash-led Candler, which is based on Debuggedy, but it can correct more information. So you can see Android's Bionic C is not only C implementation, it has some useful utility, like Debuggedy, like Azure's standard title, and some security enhancement. And about the license issue, there are several articles discussing about the way Google works around GPL, because Google used a script to pass the header file and generate the constant. Google engineer, sorry, Google claimed that the generate file is not a copyright, but someone, if you are interested, you can read the articles, the two articles. It is still a potential problem that the way Google to work around GPL license might be a problem, because they didn't do a curriculum process. But we think the way Google does is acceptable. I mean, you can check the license. So after all the policy is generated, you can check the file, for example, LibreC. So if you check the LibreC file, you can see the complete license noticement. And the Linux kernel header is just regarded as the generate information instead of the copyright material, according to Google's statement. To eliminate the problem, we just follow the way Google does. So if you have any suggestions, please discuss with us. Okay. So let's think about how to make a configurable C library implementation. So we are talking about this area is C long time, which talks to kernel as the interface of application. The first problem we encountered is the broken tool chain. So what's that? In fact, there are several utility to generate tool chain. So you can see there is a close tool. There is even close to a new next generation. And many commercial tool chain like code software. So there are many, many tool chain. And there are even LLVN-based tool chain. But Android has only one tool chain support. It's one Google engineer maintenance. So if you want to replace the default tool chain to other tool chain, to replace the built-in Google tool chain with code-associated tool chain, or other commercial tool chain, or even the tool chain you built from scratch, you might encounter the problem about the incompatibility. Before looking into the issue, let's check how tool chain works. So in the diagram, the blue one is GCC, and the red one is Bing utility, and the green one is C library. So you can see GCC is just a compiler driver which talks to several components like C preprocessor and C1, which is the real C compiler, and assemble and correct which merge these objects. And even talk to SLLD to generate the final EF image. And during the process you can see some components like CRT which stands for C runtime. And you might need some library, for example the EH, which stands for exception handling. So it's not simply a program, but a collection of several utility. This is tool chain. So you might encounter any problem resulting from every piece of the components. For example GCC found it might be crash. For example the linker might crash or generate the incorrect output. So the issues are as following. Code source tool chain doesn't use code linker as far as I know. I mean the last years release CSL9 is still BFD based GNU LD instead of golden. But Android original build flags are a bit aggressive and it applies ICF which is identical code folding which is golden linker only redundancy elimination. So you have to be very careful because Android has some aggressive flaggers. This optimization is good if your tool chain is well tuned and your source code is fixed some bugs. You can use ICF to search. I mean you can use ICF to search WebKit or you can search ICF. Oh sorry. Oh okay. Oh just ignore because it's empty. I didn't take the correct example but I have to remember that. In fact Google's optimization has some bugs so sometimes you have to work around. Okay I remember that. So if you search ICF you can see the ICF flag is set to save. ICF. But if you check the Git source tree you can understand the original configuration is ICF to all instead of ICF save. ICF all can bring the 5% size reduction but while ICF save is not. So this is a problem that Google's tool chain always applies aggressive optimization and it changes so fast. But if you use external tool chain you have to turn off the optimization but while you turn off the optimization your code might not run because Google engineer always tests one tool chain at one time. So that is a problem which leads to the extra effort for olibacy if we want to support several external tool chains as the normal open source project does. Okay let's review the procedure to build an Android compatible tool chain. You have two ways to build a tool chain. One way is bell bone style or bell mental style tool chain. You have to work with Android tree I mean the fully the full source tree and specify all system and the bionic header including several libraries and even Google's workaround. Also you can prepare standalone style building so it just looks like a traditional tool chain like code source tree tool chain but this is changing if you check the source tree or Android tool chain. There is a repository called Android tool chain you can check out this is here. There is a manifest regarding the tool chain and you will find some interesting interesting target. That is there are more targets than you expect so you can see the read me has a full target but in fact the the maker file that iron has more more configuration and they are they are they are changes of face so that is a problem you if you take the second way you have to take care the configuration and that's a header file the library and everything to be compatible with Android tool chain. So after the analyzing we get out to be fully compatible with Android tool chain we want to use the external tool chain instead of the Android Android building one so we just fix the this I mean we did some hacks but I don't have enough time to talk about that so it takes time to do some hacks so let's continue. The goal of all the machine is configurable on the optimize so there is menu configure like system so you can you can see like this sorry for that okay so you can you can enable because you can choose the target and even enable some some SOC optimization like quarkon quarkon crate or quarkon scope here and it might imply some internal rule for example the neon and you can even enable the debugging facility even adjust the alignment for memory allocator and even you can even ah sorry it's typo memory okay so you can enable the memory checking and some extensions and the build process will communicate to Android's build system we take some time to hack Android build system to be compatible with K config like system so you only have to modify one file you can check this so you only have to modify one file to press the description okay so the last part is talking about the optimizations in fact Android already applies several optimization techniques so the first one is the symbol visibility so you can see Android applied this this flag to enable the link object garbage collection so it's known to saving some libraries especially C++ library also the google engineer use a genetic programming to figure out the best fit compile time flakes so it's very crazy but this also a problem for the for the external toolchain for example the default configuration of code sorcery is already based according to mental graphics but if you apply these flakes the optimizer might crash or generate the long call because it is not the same code base of gcc so you have to be very careful about these flakes also there is an optimization called fdo which means feedback the rate of optimization the idea is very simple which is to correct your runtime information so it's a paradigm called build and build long build so you if you build the first time and the skill the is give you a program and optimize i mean the second build will will accept your profiling data and the the optimize again is called fdo so if you check the source code of all libc you can see fdo is enabled in our configuration already but it's still experimental it can bring some performance and the core size performance core size and even full-print optimization it's a visible enhancement also we have some diamond link optimization we improve that is common for gdbc but missing in bionic so we improve we implement that gnu style hash and improve the pre-linking so you can see from the diagram it's normalized so our final result is here so the diamond link link time is shortened and the symbol luga is is very very very small so the to do list is we want to follow the the way gdbc does that is to introduce option group based on portis spec so we can have better better configuration about the features about the extension of even the standard and we can write down the the the detail action item of fire sound issue if we can support such such such option groups and currently we are still working on these issues to resolve external toolchain issues we already verify console 3 toolchain but we still have some issue about the toolchain generated by bilroot or other other tool like open embedding i think it would be nice if we can collaborate with other open source project like cross tool bilroot yaktou and so on and we developed some validation tool my time is is is is up but we we modified and enhanced some some some tool so you can you can see like this we can perform some benchmarking so for example if we want to benchmarking the str len implementation you can compare gdbc and our our olibacy implementation so we want to make it more stronger and improve the unit test since we have to take take care about the standard compliance so you can compare another one is built by built by olibacy and we want to merge several more and more soc companies compute contribution so for example mvdr ti and st evison currently they do contribute to aosp but their their contribution are always wildly with each other because for example quarkon has different neon implementation so quarkon's neon optimization or quarkon's vfp optimization is not fitting the target of st evison not fitting the target ti so we want to build a a more flexible way to to let the configuration coexist and you can check the performance data is benchmarking so you can see the gdbc version compared to olibacy version so you can see the the throughput is is higher olibacy is higher than gdbc also we want to merge some open source projects for example open mp support the compiler already has has great open mp support for example gcc and even alvn but she long time has a jail jail is doomed to integrate such enhancement so that's our our our to-do list and reference okay i think my time is up