Adding an existing library or jarfile to an Android application is easy enough, but what if you wish to add it into the frameworks themselves? This post covers how to do so with an existing jarfile, though it’s also very easy to do so with the source code of the library.
In light of Google Glass going on sale to the public yesterday, I’ve decided to share some of my experiences with Glass over the past few months. My research group obtained several Glasses through the Explorer program, and we’ve put them through the ringer. While I realize that the Glass is a first release and isn’t meant to be a mainstream product, corporate moves like Google’s push to sell it to everyone have really demonstrated that Google thinks the product is good enough for the general public. After several months of using, hacking on, and developing for the Glass, I’m not impressed … and here’s why.
Clang is usually quite straightforward to use, but only for simple C/C++ programs that do not have a complex build process. The Linux kernel, however, is a completely different beast with its own custom build system, Kbuild.
This post demonstrates one (rather hackish) way to apply your Clang static analysis programs to the Linux kernel and Linux drivers, even if the modules are outside of the main Linux source tree.
I’ve assembled a list of random tips and tricks that I came across while working with Clang. Most of them serve to clear up some confusing behaviors or other complicated parts not well covered in the Clang documentation.
As mentioned in Part I of this tutorial, a Clang Plugin is similar to the LibTooling environment, except that it cannot reason about multiple source files (among other differences). In other words, it cannot remember details of more than one source file at a time, so keeping track of information about several source files (with something like global variables) is impossible.
That being said, there are instances when a Clang Plugin is still useful, like a syntax checker or formatting helper. As such, here’s how to build one that does the exact same thing as our LibTooling example from Part II.
I’ll start with a LibTooling example because I think it’s the most useful interface to Clang, as described in Part I of this tutorial. You can also use this code in the Plugin environment with just a few simple changes. Onwards to the example!
I’ve spent the last few months working with Clang, a frontend for the LLVM compiler project. Clang can parse and analyze any source code in the C language family (C, C++, ObjectiveC, etc…) and has a wonderful modular design that makes it easy to use.
If you’re looking to do static analysis on some C code, I highly recommend Clang — it’s vastly superior to other static analysis tools (like CIL … yuck!) and has decent documentation. Also, the Clang mailing list is very active and helpful if you ever find yourself stuck on something.
I personally used Clang to perform static analysis on I/O device drivers in the Linux kernel, including camera drivers and DRM drivers for graphics cards. Kernel code (especially drivers) can be very complex and difficult to analyze, but Clang allows you to handle it with ease. Let’s take a look at what you can do with Clang.
