loarabia

Clang and LLVM tutorial update

Like many projects, LLVM and Clang constantly evolve in capabilities and API design. Recently, Clang’s APIs evolved including a few breaking changes.

Today, I’m re-releasing the ClangTutorial project with two improvements.

  1. Handles the breaking changes in recent Clang builds
  2. All of the tutorial steps are now present as individual source files.

Note that tutorial 5 isn’t present. This is in and of itself because of a breaking API change from quite some time ago.

All of the project is available under the New BSD License from:

This is the first time the project will also be available from a git repository as I’m curious how mercurial compares to git (more on that later).

Lies and Statistics

It seems odd how often you can see lies conflated with Statistics.

After, reading the book “How to Lie with Statistics” by Darrell Huff and the article in The Atlantic "Lies, Damned Lies, and Medical Science" by David H. Freedman I’ve begun to think that statistics in most cases are probably no better than indicators of places where it might be interesting to look deeper at some later time.

Clang Tutorial pt 1 - 3

Clang is an Open Source C/C++/ObjC compiler that has great things going for it and two of which I care deeply about:

  1. It is licensed under a permissive license ( UIUC’s BSD-style license )
  2. It is designed and structured as a set of libraries rather than as a monolithic library or executable

The project itself (along with the LLVM project upon which Clang is based) comes with  interesting samples which tend to be fairly large and sometimes intimidating especially if you don’t know what the underlying libraries from LLVM and Clang are doing.

However, a few smaller more bite sized examples do exist on the web. I came across both of these:

Both of these were awesome but neither compiled anymore. So I set out to be the next in the yearly cycle of developers interested in Clang to update the tutorials.

The general shape of these two tutorials, led to Clang Tutorial pts. 1-3 which is effectively updated code from the previous tutorials which should build with the latest sync of Clang (at least on some Linux systems — some may still need to modify the makefile to use -fno-rtti while others may need to use the clang included headers instead of the system headers).

I’ll work on updating the code to cover the rest of the tutorials in the original posts and to make it more OS agnostic. For now, though this gets a basic useful preprocessor working on some linuxes.

Happy coding!

Debugging child processes on OS X with GDB

Hopefully, this will save folks some time who run into this.

What do you do if you want to debug a child process spawned by the parent process that gdb is attached to?

GDB’s documentation on forking would lead you to believe that this is as simple as:

set follow-fork-mode child 

That may be true on recent linux kernels (version 2.5.60 and later) but OS X doesn’t appear to have the kernel hooks to enable that. So what is a developer to do?

gdb ––wait exe

Assuming you knew nothing about the processes you were debugging (as I didn’t) but you had a hunch that it was spawning a child process (because none of the interesting breakpoints you set were hit), then you could grep through your code for a call to fork, vfork, or posix_spawn (posix_spawn was what I found and I’d bet its probably what you’ll find as well).

Assuming posix_spawn is what you’ve got, life is fairly easy (if its fork you’ll have different legwork to do) everything below assumes posix_spawn is in your code.

Set a breakpoint on the call to posix_spawn and run through the parent program to that point. Print out the path argument to posix_spawn as that is the executable that will be spawned.

Now to actually get debugging your child process.

  1. Restart your parent process with gdb attached
  2. Set GDB to break on main
  3. Run your parent process to the break point on main
  4. Fire up a new terminal window and run

    gdb ––wait child process’s name

  5. Now continue your parent process until the child is spawned by posix_spawn

This should cause the child process to spawn out of the parent and get picked up in the second instance of gdb. You can work with the child from there and as a benefit, you also have gdb attached to your parent process and can debug that as well.

I really tend to agree. Why couldn’t we have more demonstrations in science classes like this? :)

What I’m Reading (9/9/2010)

What I’m Reading (9/8/2010)