All posts by - canyon

static code analysis with scan-build while cross-compiling

The LLVM static code analyzer scan-build is easy to use, right? All you do is prepend scan-build in front of your make command. Well, there a certain circumstances where it will not work. For example, if your Makefile was generated by Eclipse for your cross-compile, scan-build will output some error messages and report zero bugs. You may be wondering, why does scan-build work with other Makefiles? To understand that, one must understand the inner workings of make and scan-build. When one runs make, it defines a bunch of rules and environmental variables. One such variable is the CC variable, which is for defining the C-Compiler. It is good practice to define the CC variable to the compiler (CC := gcc) in the Makefile and use $(CC) for the compile command. The scan-build program works by inserting itself between the compile command, which is done by replacing the CC variable with the clang analyzer.

First we should determine what targets supported by LLVM with the following command.

llc --version

Since ARM is a supported target, we’ll assume we are cross-compiling for an embedded system without an OS.

If you run the following command, it will tell you what make sets CC to. It will return cc, which is really just gcc—for the host machine. Therefore, we’ll need to set CC to the ARM cross-compiler in the Makefile.

make --print-data-base | grep '^CC ='

Anything clang doesn’t support will need to be changed. The following script converts the Eclipse generated Makefiles and source to ones that agree with clang, which serves as an example of some of the changes needed.

echo "Setting CC variable to arm-none-eabi-gcc..."
sed -i 's/RM := .*/&\nCC := arm-none-eabi-gcc/g' Debug/makefile
echo "Replacing compiler with CC variable..."
for mkfile in $(grep -rl --exclude=makefile arm-none-eabi-gcc Debug)
    sed -i 's/arm-none-eabi-gcc/$(CC)/g' $mkfile
echo "replacing -Og with one clang recognizes..."
for mkfile in $(grep -rl '\-Og' Debug)
    sed -i 's/-Og/-O2/g' $mkfile
FIND='\([ \t]*\)\(.*:[ ]"r"[ ](\)\([a-zA-Z0-9_]*\)\()[ ]:[ ]"vfpcc");\)'
REPLACE='#ifdef __clang__\n\1__builtin_arm_set_fpscr(\3);\n#else\n&\n#endif'
echo "replacing vfpcc with clang builtin"
for srcfile in $(grep -rl vfpcc .)
if [[ $srcfile != *$0 ]]
    echo "add clang builtin for vfpcc $srcfile"
    sed -i 's/'"$FIND"'/'"$REPLACE"'/g' $srcfile
echo -e "you can use scan-build for analysis.\n\n"

Assuming you’re in the Eclipse project directory, you should be able to run the analyzer with the following command—after you’ve run the script above. If you run into errors, you’ll need to resolve them and eventually add the fixes to the script. For example, you might run to an ASM goto issue.

scan-build --use-cc=/usr/bin/arm-none-eabi-gcc --analyzer-target=arm-none-eabi make -C Debug

No Comments

static code analysis of kernel modules with LLVM

When one attempts to build an out-of-tree/proprietary kernel module, it may not build or work… Static code analysis is a great way to find bugs and therefore improve product quality. One of my preferred code analysis tools is scan-build (aka clang-analyzer) because its easy to use and has great HTML output. All one has to do is prepend scan-build to your build command: scan-build make. Unfortunately, the LLVM compiler infrastructure doesn’t support the gcc extension asm goto. Therefore, if your kernel was compiled with CONFIG_JUMP_LABEL set, there will probably be numerous errors from scan-build. Fortunately, there is a workaround: undefine CC_HAVE_ASM_GOTO.

Example command-line to analyze a kernel module with scan-build.
scan-build make CFLAGS="-UCC_HAVE_ASM_GOTO"

No Comments

Being prompt

I can be kind of a nut when it comes to organizing certain things. If there is a way to minimize thought and/or processing, I will find and utilize it. One of the many reasons I love Linux/Open-Source is the freedom customize everything. By tweaking your bash prompt, one can promptly determine information about their working environment.

The prompt is generated from the contents variable PS1, which can be changed on the fly as one experiments.

## Default Prompt in Fedora
# PS1='[\u@\h: \W]\$ '
[username@host_name basedir]$ echo $PS1
[\u@\h \W]\$
[username@host_name basedir]$ PS1='[\W]\$ '
[basedir]$ PS1='[\u@\h: \W]\$ '
[username@host_name basedir]$

The escaped characters are expanded into properties of the system. For example, the default PS1 mentioned above is translated into: [username@hostname basedir]$ . For more information, RTFM: info bash and goto node “Printing Prompt” aka “6.9 Controlling the Prompt”.

lemma: I want to mention some configuration items for my preferred SCM tool: git . The color options really help with use of git in a terminal.

## Colorize git output for: branch, diff, interactive, status
$ git config --global color.ui auto
## Start gedit when text input is needed (commit message, etc)
$ git config --global core.editor gedit
## Set the merge-tool to meld (my preference) 
$ git config --global merge.tool meld

For more git configuration(s), consult the Git Pro book online .
What if you wanted something that’s not supported by the escaped characters? For example, wouldn’t it be nice to know what git branch you are on? The source of this feature is in .

How-to add git branch to prompt for single user or without sudo:
$ cp -v /usr/share/git-core/contrib/completion/ $HOME/
$ echo $'
source $HOME/
PS1=\'[\\u@\\h: \\W$(__git_ps1 " (%s)")]\\$ \'' >> ~/.bashrc
## ... or just add the following lines to .bashrc (without the #)
# source $HOME/
# PS1='[\u@\h: \W$(__git_ps1 " (%s)")]\$ '
How-to add git branch to prompt for all users (with sudo):
$ sudo cp -v /usr/share/git-core/contrib/completion/ /etc/profile.d

If you keep in mind these files get parsed when you login, your prompt should look like: [username@hostname git_repo_dir (master)]$ . Now we have a bunch of useful text but not really presented in a useful way; this is where the color comes in. One can change the color of the output (even in scripts) with escape sequences. For example, the \e[34m sets the output to blue, which is followed by the text you want to echo (“Hello Blue World”) followed by a reset back to the default color environment \e[0m .

$ echo -e 'Hello \e[34m'"Blue"'\e[0m World'
Hello Blue World

Personally, I prefer to use a different method, which uses tput from the ncurses package because it looks cleaner.

$ echo -e "Hello $(tput setaf 4)Blue$(tput sgr0) World"
Hello Blue World

By default, Fedora is configured with a pallet of 256 terminal colors. The following code will print the full color map and perhaps provide some understanding of how the tput command is used.

for ((x=0; x<$(tput colors); x++));
  echo -e "${x}:\t$(tput setaf ${x})color\t$(tput bold)bold\t$(tput sgr0; tput setaf 0; tput setab ${x})background$(tput sgr0)"; 

Some of the subtleties of the command above: once you set a property its stays set and sgr0 resets all the properties. Since you have RTFM by this point, you know that any non-printing characters (the ones that set color) need to be surrounded with escaped brackets \[\] in a prompt. In other words, put escaped brackets around any tput command sequence.

tip: tput reset will reset all the terminal properties. While you’re playing around with the prompt ( PS1 ), you may need to reset everything.

Unfortunately, I sometimes have to work in a environment where Ubuntu is the Linux distribution used by the developers. In most cases, a chroot provides an easy clean way to: not be held hostage by the build environment. Consequently, I like to know what environment I’m building in so I put the chroot in my in my prompt, which is same format you would see in a mock chroot in shell mode.

.bashrc – colored prompt
if [ "x$debian_chroot" != "x" ]
## We're in a debian chroot
  echo -e "$(tput bold)CHROOT: $debian_chroot $(tput sgr0)"
  JAIL='<\[$(tput bold)\]${debian_chroot}\[$(tput sgr0)\]>'
## No Jail
if [ -z "$PS1" ]
  source $HOME/
  if [ "$(tput colors)" = "256" ]
    PS1="${JAIL}[\[$(tput setaf 33)\]\u@\h \[$(tput bold;tput setaf 46)\]\W\[$(tput sgr0; tput setaf 15)\]\$(__git_ps1 \" (%s)\")\[$(tput sgr0)\]]\$ "
    PS1="${JAIL}[\[$(tput setaf 6)\]\u@\h \[$(tput setaf 2)\]\W\[\e[0;97m\]\$(__git_ps1 \" (%s)\")\[$(tput sgr0)\]]\$ "

These are the resulting prompt from add the above to .bashrc .

colored prompt
[username@hostname sandbox_dir]$ 
colored prompt inside a git repo directory
[username@hostname git_repo_dir (branchname)]$ 
colored prompt inside a debian chroot
<chrootname>[username@hostname chroot_dir]$ 

Now that you have the prompt color coded, its easier to parse for the information you need at the moment. I’ll leave you with one last tip: consider changing the root prompt to an attention color—like red—so you can reduce those late night mistakes as root…

No Comments

Fedora 18, fglrx and XvBA

Since I’ve already upgraded my machines to Fedora 19, I figured I should finish this entry… As a side note, I updated using FedUp , which has worked mostly flawlessly on all my machines.

One of the reasons people use the RPM Fusion drivers is for ease of updating packages, which I fully understand. Consequently, one can update with the AMD/ATI variant, which doesn’t seem to be mentioned often or at all. All you need is DKMS and my little patch (see below) for the AMD Catalyst. The Linux Engineering team at Dell wrote DKMS (Dynamic Kernel Module Support). DKMS is a framework for Linux drivers that are not part of the Linux source: like proprietary drivers. When you have DKMS installed and update the kernel, DKMS will build the module automatically.

diff -puNr fglrx-13.4.orig/common/lib/modules/fglrx/build_mod/firegl_public.c fglrx-13.4/common/lib/modules/fglrx/build_mod/firegl_public.c
--- fglrx-13.4.orig/common/lib/modules/fglrx/build_mod/firegl_public.c	2013-01-15 10:42:53.000000000 -0500
+++ fglrx-13.4/common/lib/modules/fglrx/build_mod/firegl_public.c	2013-03-09 11:09:39.147353586 -0500
@@ -98,6 +98,9 @@
 // ============================================================
+#ifndef VM_RESERVED
 // always defined
 #define __AGP__BUILTIN__
diff -puNr fglrx-13.4.orig/common/lib/modules/fglrx/build_mod/ fglrx-13.4/common/lib/modules/fglrx/build_mod/
--- fglrx-13.4.orig/common/lib/modules/fglrx/build_mod/	2013-01-15 10:42:53.000000000 -0500
+++ fglrx-13.4/common/lib/modules/fglrx/build_mod/	2013-03-14 21:23:10.378185394 -0400
@@ -199,6 +199,9 @@ cd $current_wd
 # ==============================================================
 # locate and verify contents of kernel include file path
+## Create link to version.h
+link /usr/src/kernels/${uname_r}/include/generated/uapi/linux/version.h /usr/src/kernels/${uname_r}/include/linux/version.h
 # verify match with respective line in linux/version.h
 # sample: #define UTS_RELEASE "2.4.0-test7"

The first part of the patch defines VM_RESERVED , which was removed/changed as of Linux 3.7 . The second part of the part of the patch adds to the install scripts used by DKMS install, which creates a link to version.h . If you’ve tried to install fglrx with AMD’s installer, it probably will complain about a missing version.h file, which this patch fixes.

Installing AMD Catalyst drivers

## 1. Install DKMS
yum install dkms
## 2. Install dependencies for fglrx
yum install bash chkconfig fontconfig freetype glibc libgcc libICE libSM libstdc++ libX11 libXcursor libXext libXfixes libXinerama libXrandr libXrender libXxf86vm nx ocl-icd-devel qt qt-x11
## 3. Restart the computer
## 4. Unzip the AMD file you've downloaded
## 5. Extract the Catalyst package contents into a folder called fglrx-13.4
./ --extract fglrx-13.4
## 6. Patch the installer
patch -p0 <fglrx-13.4-fc18.patch
## 7. Enter the directory to start the install
cd fglrx-13.4
## 8. Install the patched AMD driver
./ 13.4 --install

Updating packages with the AMD’s Catalyst

AMD’s installer moves a few things around and directs the symlinks to their libraries. AMD provides some scripts to move things around.

## Switch to Open-Source drivers
$(rpm --eval %{_libdir})/fglrx/switchlibGL intel && $(rpm --eval %{_libdir})/fglrx/switchlibglx intel
## You want to update packages...
yum update
## Switch to AMD drivers
$(rpm --eval %{_libdir})/fglrx/switchlibGL amd && $(rpm --eval %{_libdir})/fglrx/switchlibglx amd

XvBA driver updates

I’ve updated the XvBA driver SRPM to be a little easier for those not use to debugging: added some hard to miss messages when certain build error occurs and updated the build requirements. In addition, I finally read the AMD license—unless a lawyer tells me otherwise—I have included XvBA-SDK in the SRPM. Perhaps, I will make a devel package to install the XvBA-SDK.
Consequently, I also changed the build process when building against a AMD/ATI install the process is a little bit different: amdbuild must be defined to 1 .

rpmbuild -bb SPECS/libva-xvba-driver.spec --define='amdbuild 1'

Without the define option, the package is built for the RPM Fusion drivers. Since I made the above changes, I decided there was no reason I shouldn’t build the RPMS for people.
Fedora 17 XvBA links:
Fedora 18 XvBA links:

Again, if anybody has issues or questions please feel free to comment.


Have your Pi and eat it too

Yesterday was a big day for embedded Linux and Open-Source. While I was reading what’s new via RSS feeds, I came across a slashdot article: “Raspberry Pi goes Open-Source”. As I have mentioned before, some of the Linux running on Raspberry Pi is closed source/proprietary. One of the big gripes in the open-source community is the secrecy about video hardware. Understandably, video chip manufactures want to protect their IP (Intellectual Property)—to the point of not describing what the registers in the chip do. Really, how much of it is novel? True, one could reverse engineer the GPU easier with this information. Consequently, most of the FOSS graphics drivers are reversed engineered anyway and considering that a new graphics core is released every year, is this really necessary? Okay, I’m sure you get my opinion at this point.

In short, Raspberry Pi has worked with Broadcom to Open Source ARM userland, which is a huge step because it is the first vendor to open their mobile GPU. Hopefully, other vendors will follow. Get the source for the VideoCore via GIT. Do you see anything novel in the source? If you believe in open-source, thank Broadcom for this contribution.

No Comments

Fedora 17, fglrx and XvBA

I decided to finally update my computer to Fedora 17 (Beefy Miracle) this past weekend. Overall, the upgrade went smoothly considering there is a bunch of lint on my system because I’ve been upgrading it since FC8. I did run into some graphics issues…

Since I play games and graphics chips are black-boxes, I use the ATI/AMD binary blob: Catalyst aka fglrx. Using the binary blob is going to be a problem when I start using Qt 5 because it depends on XCB instead of XLIB. As I’ve mentioned before, Fedora is a pure Linux distribution. Therefore, you’ll have to use methods outside of Fedora to install proprietary drivers. The “recommended method” is to use the RPM Fusion drivers. The RPM Fusion drivers did not work for me under Fedora 16. Consequently, using the installer from AMD did work with Fedora 16.

I’m pleased to say the RPM Fusion drivers for Fedora 17 did work but not completely. Modern day graphics cards have hardware that assist in decoding video, which is another reason I use the proprietary drivers. When AMD’s XvBA is not in use, the CPU load ranges from 30-50% but I digress. After installing the RPM Fusion catalyst drivers, I immediately built the XvBA rpm and installed it. Unfortunately, when I started VLC the video acceleration didn’t work. Since I firmly believe in the open-source way, I filed a bug. A possible fix: make libGL part of the alternates like java is. Consequently, I’ll be using the proprietary driver until the bug is resolved or the open-source community receives the secret sauce from AMD.

Quick How-to

# 1. Download the catalyst driver from AMD (aka fglrx)
# 2. Decompress/unzip the download
unzip amd-driver-installer-catalyst-*.zip
# 3. Install AMD's version of fglrx. NOTE: RPM-Fusion driver does not work.
# 4. Restart
# 5. Make sure the catalyst/fglrx driver is working
# 6. Download XvBa Source RPM
# 7. Build RPM
rpmbuild --rebuild libva-xvba-driver-0.8.0-4.fc17.src.rpm
# 8. Install the built RPM
yum install ~/rpmbuild/RPM/`uname -m`/libva-xvba-driver-0.8.0-4.fc17.x86_64.rpm

Please feel free to comment if you have any issues.


Fedora 18, fglrx and XvBA


Sweet Raspberry Pi

I try to stay up-to-date with technology… While procrastinating getting up-to-date, came across Raspberry Pi. The Raspberry Pi (model B) is a $35 single board computer. I’ll let the picture do the talking.

Raspberry Pi Isometric View

Raspberry Pi

When I read that the Broadcom chip (BCM2835) has an ARM core (ARM1176JZF-S), I thought, “Sweet, I can run Linux on this”. At that point, I knew I had to have one… but no idea what I’d use it for. Since the organization was in the UK, I knew I would have to wait and wait I did. When I received my Raspberry Pi from MCM electronics, I researched putting my distribution of choice: Fedora. Consequently, the Fedora distribution is pure; that is, only open-source content is distributed by Fedora, which means the closed-source libraries that utilize the hardware—such as, the video core acceleration—are not distributed with Fedora. Therefore, the OS is officially referred to as Raspberry Pi Fedora Remix, which was at one time, the Raspberry Pi distribution choice because some students at Seneca College modified and compiled the Fedora ARM so it would utilize the hardware benefits such as the floating-point unit.

No Comments