Jongy’s blog

Assert Rewriting - A GCC plugin - part 2

2020-05-15T00:00:00+00:00

This post continues from where we stopped in part 1 (to recall - last thing we’ve done was a simple modification of a single node in the AST, and we saw how it reflected in the result)

Today we’ll build the logic of assert rewriting and also dive deeper into GCC’s API. We’ll try to improve typical assert messages like:

to something nicer:

Well, maybe not the entire of it, but the core parts :) The full thing can be found in the plugin.

Asserts

What’s the code in assert, actually? Is it a macro? A function? Something else? The answer depends on which C library you use (assert comes from assert.h which is a part of standard C, distributed with the C library / libc). We’ll follow glibc which is probably what you have installed. Most desktop Linux distributions use it, so most likely you have it as well. See this SO question for instructions on determining the libc your GCC uses.

We can see what’s underneath assert this way:

$ cat dummy.c
#include <assert.h>
assert(1 == 1)
$ gcc -E dummy.c

gcc -E doesn’t compile (indeed, this code wouldn’t compile) - it runs the preprocessor (doing all includes and macros substitution), and dumps the result to the standard output.

These are the final few lines:

# 2 "dummy.c" 2
((void) sizeof ((
# 2 "dummy.c"
1 == 1
# 2 "dummy.c" 3 4
) ? 1 : 0), __extension__ ({ if (
# 2 "dummy.c"
1 == 1
# 2 "dummy.c" 3 4
) ; else __assert_fail (
# 2 "dummy.c"
"1 == 1"
# 2 "dummy.c" 3 4
, "dummy.c", 2, __extension__ __PRETTY_FUNCTION__); }))

The # marks in the output are hints the preprocessor gives to the compiler - they can be ignored. __extension__ can also be ignored, it’s used to suppress certain warnings. Removing them, we remain with:

((void) sizeof ((1 == 1) ? 1 : 0), ({ if (1 == 1) ; else __assert_fail ("1 == 1", "dummy.c", 2, __PRETTY_FUNCTION__); }))

The sizeof is the first operand of the comma operator, so its result is really unused (it’s also voided…). A comment in glibc’s source explains it’s there to trigger warnings possibly masked due to the previous use of __extension__.

The second operand is the assert condition itself: if the condition passes, do nothing; else, call __assert_fail, give it some info (the stringified expression, file name, line number and function name) and it’ll do the dirty work.

To patch asserts, we first need to identify them in the AST. Let’s see how this code we just saw is represented.

Asserts in the AST

Write this dummy.c:

#include <assert.h>

void test(int n) {
    assert(n == 42);
}

Remember our basic.c plugin from part 1? We’ll change it to run debug_tree(DECL_SAVED_TREE(t)), and compile dummy.c with it. Plugin code is here.

In this post I’ll show shortened versions of AST prints, we already understand their structure so I can omit irrelevant parts.

 <bind_expr ...
    ...
    body <statement_list ...
        ....
        stmt <bind_expr ...
            body <cond_expr ...
                arg:0 <eq_expr ...
                    arg:0 <parm_decl ... n>
                    arg:1 <integer_cst ... constant 42>
                arg:1 <nop_expr ... type <void_type ...
                    arg:0 <integer_cst ... constant 0>
                arg:2 <call_expr ...

First we see a BIND_EXPR inside a STATEMENT_LIST, inside another BIND_EXPR! The outer bind is the function block. It contains a STATEMENT_LIST, which is a grouping of multiple, sequential statements. Inside the list there’s another BIND_EXPR - this is the block created by the assert (see the ({ }) wrapping in the generated code?).

Now, the body of that last bind is the core logic. It is a COND_EXPR, which represents an if, or a ternary operator. It has 3 operands: the condition, an expression to be evaluated if the test passes (if { ... } clause) and an expression to be evaluated if the test fails (else { ... } clause).

The condition is an EQ_EXPR, which tests for equality between its 2 operands: our PARM_DECL of n, and the constant 42.
The if { ... } clause is a NOP_EXPR whose operand is the constant 0. NOP_EXPRs represent conversions which don’t require code generation (e.g int *p; (char*)p;). This NOP_EXPR has type void_type, so it’s a void cast; that is, we have (void)0. This is the common “empty statement” GCC uses, for when it must put some statement (see build_empty_stmt in GCC, which generates it).
The else { ... } clause is a CALL_EXPR which represents a function call: the call to __assert_fail.

Take a deeper look on the CALL_EXPR itself:

...
  <call_expr ...
      fn <addr_expr ...
          ... arg:0 <function_decl ... __assert_fail>
      arg:0 ...
      arg:1 ...
      arg:2 ...
      arg:3 ...
...

It has the called function in fn, and 4 arguments. The called function is an ADDR_EXPR: these nodes represents the address of an object. The object whose address is used here is the FUNCTION_DECL of __assert_fail.

I think that’s enough to write code that “macthes” on AST nodes which are asserts - that is, the main COND_EXPR implementing them. The code (which I also use in the plugin) is as follows:

static bool is_assert_fail_cond_expr(tree expr) {
    if (TREE_CODE(expr) != COND_EXPR) {
        return false;
    }

    tree expr_else = COND_EXPR_ELSE(expr);
    return (
        TREE_CODE(COND_EXPR_THEN(expr)) == NOP_EXPR &&
        TREE_CODE(expr_else) == CALL_EXPR &&
        TREE_CODE(CALL_EXPR_FN(expr_else)) == ADDR_EXPR &&
        TREE_CODE(TREE_OPERAND(CALL_EXPR_FN(expr_else), 0)) == FUNCTION_DECL &&
        // IDENTIFIER_POINTER(DECL_NAME(...)) gets the (null-terminated) name string from a declaration.
        0 == strcmp("__assert_fail", IDENTIFIER_POINTER(DECL_NAME(TREE_OPERAND(CALL_EXPR_FN(expr_else), 0))))
    );
}

Traversal of function’s AST

We saw that the AST may contain nested BIND_EXPRs and STATEMENT_LISTs. This calls for some recursive traversal, displayed in this pseudocode:

traverse(expr)
    if expr is BIND_EXPR
        expr = bind body of expr

    if expr is STATEMENT_LIST
        for each statement in list
            traverse(statement)
    else
        if is_assert_fail_cond_expr(expr)
            patch assert <-- here the magic happens

traverse(DECL_SAVED_TREE(function))

We’ll use the implementation of it in our next example, but I won’t elaborate on it. If you’re interested you can see it the plugin code.

Assert Rewriting

Let’s start with something simple: generate a nicer “assert failed” message for the assert(n == 42) we had earlier. Instead of the usual Assertion `n == 42' failed, we’ll aim for %d == 42, where %d is the runtime value of the “bad” number.

We can retain the COND_EXPR condition intact, and just replace the call to __assert_fail with our print. Basically, for the given assert, we just need to generate the equivalent of printf("%d == %d", n, 42). Code will be generated based on input, without hard-coding values, so if the assert changes to n == 43, our plugin will generate printf("%d == %d", n, 43).

Recall we had the EQ_EXPR, being the assert condition.

  <eq_expr ..
      arg:0 <parm_decl .. n>
      arg:1 <integer_cst .. constant 42>

If we can construct a printf call and use these 2 as arguments, that might work.

How can we construct calls? build_call_expr! Very obvious name. Actually, it wasn’t that obvious to me originally… and I found build_function_call instead, which caused me huge problems we’ll discuss later.

Anyway, build_call_expr accepts 2 + N arguments: the function to be called (e.g FUNCTION_DECL or a function pointer); N, the number of arguments, and then the arguments themselves.

How can we get the FUNCTION_DECL of printf? In a quick look for functions named “lookup”, “search”, “identifier” etc in tree.h I couldn’t find anything related. We might not be acquainted with GCC’s codebase, but we know the compiler’s behavior a bit… When does GCC search for identifiers in the compilation scope? Right before a search fails and it emits implicit declaration of function!

Search “implicit declaration of function” in GCC’s code (you can narrow down the search directories to gcc/{c,c-family}, where the C frontend code is). All non-comment results are in c-decl.c. Actually, all of them are in implicit_decl_warning. This function is called in 2 sites from implicitly_declare, which itself is called from build_external_ref in c-typeck.c.

build_external_ref gets a tree id which is an identifier tree - these are common, identifier trees are e.g the DECL_NAME of declarations. It calls lookup_name(id) then runs some more Objective-C-related stuff which we don’t care about, and finally checks if decl is a NULL_TREE - if so, it calls implicitly_declare.

So we’ll use get_identifier to get the identifier node, then use lookup_name (which resolves the symbol according to C scoping rules). Together, lookup_name(get_identifier("printf")).

Last thing we need is to generate the arguments. First argument is a string constant, which we can build with build_string_literal. Then, we extract the other arguments from the assert condition. Our new patch_assert function has the COND_EXPR. Get the condition with COND_EXPR_COND then extract the 2 sides of EQ_EXPR with TREE_OPERAND.

Wrapping them all together, we get:

tree left = TREE_OPERAND(COND_EXPR_COND(cond_expr), 0);
tree right = TREE_OPERAND(COND_EXPR_COND(cond_expr), 1);
tree fmt = build_string_literal(sizeof("%d == %d\n"), "%d == %d\n");

tree call = build_call_expr(lookup_name(get_identifier("printf")), 3, fmt, left, right);

// embed it in the expression - replace __assert_fail() call with it
COND_EXPR_ELSE(cond_expr) = call;

The full code as of this point can be seen here.

Create a dummy main() to invoke our test function with the assert.

void test(int n);

int main(void) {
    test(5);
    return 0;
}

Add #include <stdio.h> in dummy.c - our code now depends on printf’s declaration.

#include <assert.h>
#include <stdio.h>

void test(int n) {
    assert(n == 42);
}

Compile and run:

$ g++ -g -I`gcc -print-file-name=plugin`/include -fpic -shared -o basic.so basic_rewrite.c
$ gcc -fplugin=./basic.so dummy.c main.c -o main
$ ./main
5 == 42

Cool! It worked! And if we change the 5 or the 42, we’ll see the values changing accordingly.

Complex expressions

Current prints can be made nicer, but the bigger problem is - we can handle only a single type of expressions. What if function calls are involved? Logical operators like && and ||? Binary expressions like + and *?

Obviously we’d like to follow them and print their operands / sub-expressions as well; It’s a recursive structure so our code should be recursive as well.

Here’s the logic I thought of:

Recursively follow both operands of logical & binary operators using depth-first search.
When going one level deeper, wrap operand with parentheses.
Leaf expressions are collected in a list, eventually passed as arguments to printf.

The code for this part, including explaining comments: (full code)

// convert the type of 'expr' to text representing its operation, for example "+"" for PLUS_EXPR.
// this list is shortened for brevity.
static const char *get_expr_op_repr(tree expr) {
    const char *op;

    switch (TREE_CODE(expr)) {
    case EQ_EXPR: op = "=="; break;
    case NE_EXPR: op = "!="; break;
    case TRUTH_AND_EXPR:
    case TRUTH_ANDIF_EXPR: op = "&&"; break;
    case TRUTH_OR_EXPR:
    case TRUTH_ORIF_EXPR: op = "||"; break;
    case PLUS_EXPR: op = "+"; break;
    case MINUS_EXPR: op = "-"; break;
    case MULT_EXPR: op = "*"; break;
    case TRUNC_DIV_EXPR: op = "/"; break;
    default: op = NULL; break;
    }

    return op;
}

// the core logic: recursively calls itself for operands of binary operators.
// wtf? c++? vec<..> *& ??
static char *create_expression_repr(tree expr, vec<tree, va_gc> *&args) {
    char buf[1024];

    const char *op = get_expr_op_repr(expr);
    // got a binary operator for this expression?
    if (NULL != op) {
        // then it's binary! descend into its 2 operands.
        char *left = create_expression_repr(TREE_OPERAND(expr, 0), args);
        char *right = create_expression_repr(TREE_OPERAND(expr, 1), args);
        // wrap them up together
        snprintf(buf, sizeof(buf), "(%s) %s (%s)", left, op, right);
        free(left);
        free(right);

        return xstrdup(buf);
    }

    // add current expression to arguments list.
    // since we descend the tree left-to-right, the order of arguments for printf will match the
    // order in this list.
    vec_safe_push(args, expr);
    // use %d for everything to keep things simple.
    return xstrdup("%d");
}

static void patch_assert(tree cond_expr) {
    vec<tree, va_gc> *v;
    vec_alloc(v, 0);

    char *fmt = create_expression_repr(COND_EXPR_COND(cond_expr), v);

    // format comes first.
    vec_safe_insert(v, 0, build_string_literal(strlen(fmt) + 1, fmt));
    free(fmt);

    // UNKNOWN_LOCATION? more on that below.
    tree call = build_call_expr_loc_vec(UNKNOWN_LOCATION, lookup_name(get_identifier("printf")), v);
    vec_free(v);

    COND_EXPR_ELSE(cond_expr) = call;
}

A few things about the code, before we run it.

First and most important, C++?? Quite surprising. At least, I was surprised… Although it’s a well-known fact that GCC is written in C++, since the API until now has been quite C-ish, this fact has slipped my mind. The first time I realized again C++ is mixed here was when I searched for call sites of build_string_literal. Its definition in tree.c takes 3 arguments, but all calls to it were passing only 2. Then I looked in its declaration, and saw it has a default parameter tree = char_type_node. AFAIK, C has no default arguments :(

GCC’s codebase is C++ but many areas of the code are indeed very C-like (making no use of classes and making heavy use of macros). However, some areas do make use of C++ to its full extents, including heavy use of templates. This sums it up well:

About the UNKNOWN_LOCATION: it is a special constant of type location_t. location_ts are used widely around GCC code. These represent the source code location of expressions, declarations etc - many tree types have a location field, which can be accessed with EXPR_LOCATION / SET_EXPR_LOCATION. These help GCC direct its compilation errors/warnings at the right spot in your source code, and are probably used for other things as well (e.g generating debug info). You have the location_t of a node in debug_tree output, it is right before the closing >, for example dummy.c:4:5 start: dummy.c:4:5 finish: dummy.c:4:5. UNKNOWN_LOCATION can substitute any location, but it prevents GCC from relating diagnostics messages with our source code. In the plugin code, I take the location of the core COND_EXPR once, then use it everywhere.

Okay, let’s try to run (reminder - full code is here).

Change dummy.c to:

#include <assert.h>
#include <stdio.h>

void test(int n) {
    assert(n % 2 == 0 && n - 100 == 150);
}

Compile everything, and run…

$ ./main
((1) == (0)) && ((5) == (250))

Awesome!

By the way, notice anything weird above? The right expression appears to be n == 250, not n - 100 == 150 as we have written. Well, even though our plugin runs quite early (before most optimizations take place), some processing was already done on the AST, and expressions have changed.

More complexity

Any problems with current logic? We’ll explore now.

Double evaluation

Let’s start with this: what if instead of n, we embed a function call expression?

#include <assert.h>
#include <stdio.h>

int func(int n) {
    printf("func called!\n");
    return n + 7;
}

void test(int n) {
    assert(func(n) % 2 == 0 && n - 100 == 150);
}

Compile and run:

$ ./main
func called!
func called!
((0) == (0)) && ((5) == (250))

Twice? But we called it once only! Problem is, we took the expressions from assert and placed them in our printf. With variables that’s probably okay, but with function calls (i.e CALL_EXPRs) - each appearance of them will lead to a function call. We can’t just “clone” expressions that have side effects!

In the previous post I presented a simple example of “rewriting” an assert in Python. The condition contained a function call, so we stashed the result in a temporary variable which was used multiple times, instead of calling the function again.

So… I was about to develop something similar here. Before diving into it, I spent some time reading the various documents on expression trees, and was lucky to find the savior: SAVE_EXPR. This node does exactly what I needed! A SAVE_EXPR can wrap another expression (which might have side effects), then the SAVE_EXPR itself can be used instead, and it will provide the same value. No matter how many times you clone the same SAVE_EXPR, the underlying expression is evaluated at most one time!

Instead of creating variables for all temporary values, all I needed to do was to wrap all expressions with SAVE_EXPR. I won’t go into details on how it’s done here, but can see it in the plugin.

Lesson here: get acquainted with the various types of trees, they might come in handy.

Short-circuts

What’ll happen with the following code:

#include <assert.h>
#include <stdio.h>

void test(int *p) {
    assert(p != NULL && *p == 5);
}

#include <stddef.h>

void test(int *p);

int main(void) {
    test(NULL);
    return 0;
}

Well, the assert should fail - p != NULL is false. But if we run it…

$ ./main
[1]    602485 segmentation fault (core dumped)  ./main

Da hell. What’s going on here?

The problem lies within our static processing of the expression. We create a printf containing all operands of a complex expression; but in reality, due to short-circuiting, parts of the expression are not evaluated at all:

With &&: 5 == 4 && i_am_not_evaluated()
With ||: 5 == 5 || i_am_not_evaluated().

Following these basic rules of && and ||, it gets more complex with larger expressions:

((4 == 3 || evaluated()) && 1 == 0) && not_evaluated())

Well, obviously the runtime result of expressions must be taken into account when creating the assert message…

Runtime generation

At this point I made a stop and went to see how py.test does its rewriting (after all, this whole idea came from it). The core logic of rewriting is in this file; it’s very long, so I decided it will be easier to look in the output it generates instead :) Lucky for us py.test assert rewriting outputs Python (byte)code and not assembly.

Take this simple test file:

def func(n):
    return n + 3


def test_a():
    assert func(4) == 5 and func(5) == 8

pyc files are written for test files; these include the modifications made by assert rewriting, so we just need to decompile the file generated after one test run.

Grab uncompyle6, a nice Python decompiler. I recommend using Python 3.6/3.7 because uncompyle6 failed for me on 3.8.

Easiest done with Docker:

$ docker run --rm -it python:3.6 /bin/bash
docker$ pip install pytest uncompyle6
docker$ python -m pytest test.py  # test.py is the simple test file from above
docker$ uncompyle6 __pycache__/test.cpython-36-pytest-*.pyc

It will output a very long piece of Python code, compared to how simple and short our assert originally was. It also makes use of too many obscure character sequences, and Jekyll (the framework rendering this site) wouldn’t agree to render it, so I put it here instead.

First thought I had in mind when I saw this was “Too bad Python doesn’t have SAVE_EXPR… :)”. It would really alleviate the use of all temporary variables there.

Anyway, the logic is roughly: (omitting all irrelevant extra/temporary variables, etc)

res1 = func(4) == 5
res_both = res1
if res_both:
    res2 = func(5) == 8
    res_both = res2
if not res_both:
    # assert failed!
    # res1 holds the result of the left expr
    # res2 holds the result of the right, only if res1 is True!
    ...

So py.test rewrote the entire condition, while conforming to short-circuiting rules: it won’t exeucte the right-hand part of the and expression if the left-hand part failed. It also collects information during execution, to be used if the condition fails eventually.

We can try doing what py.test does: replace the condition completely, and run it part by part. But this means that if our logic is broken, we can break the assert condition and its result might come wrong, which is bad. Instead, I decided to add new code only in the “failed” branch of the condition, so even if my code introduces some errors, they won’t affect the code in the “happy flow” (i.e, when everything works). The new code will walk the condition tree in runtime and create the assert message. Since all sub expressions are wrapped in SAVE_EXPR, “re-walking” the condition won’t re-evaluate anything.

The generated logic for assert(x == 1 && y == 2); will look roughly like this C code:

if (x == 1 && y == 2) {
    // all good
} else {
    if (x == 1) {
        // note the "(...) &&"" part, telling us this is the right-hand part of &&.
        printf("(...) && (%d == 2)", y);
    } else {
        printf("%d == 1", x);
    }
}

And if we add more complexity? for assert((x == 1 && y == 2) || z == 3) it will be:

if ((x == 1 && y == 2) || z == 3) {
    // all good
} else {
    printf("(");
    if (x == 1) {
        printf("(...) && (%d == 2)", y);
    } else {
        printf("%d == 1", x);
    }
    printf(") || (%d == 3)", z);
}

The real logic happens to be a bit more complex :P Mostly because generation has to be recursive (because expressions are recursive). Following are the relevant parts, commented. The core function is make_conditional_expr_repr which recursively calls itself on the expression tree branches, creating statements that print the “assert fail” message for each part. The statements are conditional - based on the runtime value of expressions, they will print appropriate messages.

I omitted many parts for brevity (i.e, no SAVE_EXPRs handling here).

// builds a COND_EXPR
static inline tree _build_conditional_expr(location_t colon_loc, tree ifexp,
    tree op1, tree op1_original_type, tree op2, tree op2_original_type) {

#if GCCPLUGIN_VERSION >= 8001 // a32c8316ff282ec
    return build_conditional_expr(colon_loc, ifexp, false, op1, op1_original_type,
        colon_loc, op2, op2_original_type, colon_loc);
#else
    return build_conditional_expr(colon_loc, ifexp, false, op1, op1_original_type,
        op2, op2_original_type);
#endif
}

static tree printf_decl;

// builds a printf(format, ...) call with given args
static tree make_printf(const char *format, vec<tree, va_gc> *args) {
    tree fmt = build_string_literal(strlen(format) + 1, format);
    if (args) {
        vec_safe_insert(args, 0, fmt);
        tree call = build_call_expr_loc_vec(UNKNOWN_LOCATION, printf_decl, args);
        vec_free(args);
        return call;
    } else {
        return build_call_expr_loc(UNKNOWN_LOCATION, printf_decl, 1, fmt);
    }
}

static tree make_conditional_expr_repr(tree expr) {
    const enum tree_code code = TREE_CODE(expr);

    // for TRUTH_ANDIF_EXPR/TRUTH_AND_EXPR:
    // * if left fails, we print only left
    // * if right fails, we print (...) && right
    // * if both pass, we print nothing
    if (code == TRUTH_ANDIF_EXPR || code == TRUTH_AND_EXPR) {
        tree stmts = alloc_stmt_list();
        // statements that print the left side
        append_to_statement_list(make_conditional_expr_repr(TREE_OPERAND(expr, 0)), &stmts);

        tree left_stmts = stmts;

        stmts = alloc_stmt_list();
        // statements that print the right side
        append_to_statement_list(make_printf("(...) && (", NULL), &stmts);
        append_to_statement_list(make_conditional_expr_repr(TREE_OPERAND(expr, 1)), &stmts);
        append_to_statement_list(make_printf(")", NULL), &stmts);

        tree right_stmts = stmts;

        // if "left" condition passes, run "right" statements. else run "left" statements.
        tree cond = _build_conditional_expr(UNKNOWN_LOCATION, TREE_OPERAND(expr, 0),
            right_stmts, NULL_TREE,
            left_stmts, NULL_TREE);

        return cond;
    }
    // for TRUTH_ORIF_EXPR/TRUTH_OR_EXPR
    // * if left and right fail, we print both
    // * if any pass, we print nothing
    else if (code == TRUTH_ORIF_EXPR || code == TRUTH_OR_EXPR) {
        tree stmts = alloc_stmt_list();
        append_to_statement_list(make_printf("(", NULL), &stmts);
        append_to_statement_list(make_conditional_expr_repr(TREE_OPERAND(expr, 0)), &stmts);
        append_to_statement_list(make_printf(") || (", NULL), &stmts);
        append_to_statement_list(make_conditional_expr_repr(TREE_OPERAND(expr, 1)), &stmts);
        append_to_statement_list(make_printf(")", NULL), &stmts);

        // if expr passes - print nothing (build_empty_stmt branch).
        // if expr fails - print both
        return _build_conditional_expr(UNKNOWN_LOCATION, expr,
            build_empty_stmt(UNKNOWN_LOCATION), NULL_TREE,
            stmts, NULL_TREE);
    }
    // for others - we always print them - because this code gets called only if the expression it reprs
    // has failed, because the &&/|| code guards it.
    else {
        tree stmts = alloc_stmt_list();

        const char *op = get_expr_op_repr(expr);
        // if it's a binary expression - print both sides.
        if (op != NULL) {
            char format[64];
            (void)snprintf(format, sizeof(format), " %s ", op);

            append_to_statement_list(make_conditional_expr_repr(TREE_OPERAND(expr, 0)), &stmts);
            append_to_statement_list(make_printf(format, NULL), &stmts);
            append_to_statement_list(make_conditional_expr_repr(TREE_OPERAND(expr, 1)), &stmts);
        } else {
            // it's a plain value - print it alone.
            vec<tree, va_gc> *args;
            vec_alloc(args, 2); // 1 for the format
            args->quick_push(expr);

            append_to_statement_list(make_printf("%d", args), &stmts);
        }

        return stmts;
    }
}

static void patch_assert(tree cond_expr) {
    printf_decl = lookup_name(get_identifier("printf"));
    COND_EXPR_ELSE(cond_expr) = make_conditional_expr_repr(COND_EXPR_COND(cond_expr));
}

Full code for this part is here.

Let’s try it with the previously crashing snippet. Compile and run it again:

$ ./main
0 != 0

Good. It prints only the left part of &&. Now change test(NULL) to int n = 4; test(&n) and run again:

$ ./main
(...) && (4 == 5)

As expected. And now with ||, change the assert to assert(p == NULL || *p == 5) and run:

$ ./main
(75904660 == 0) || (4 == 5)

Awesome :)

Alright, that’s enough for this post. There are a few more core features/concepts in the plugin, but this post is really long enough already, kudos for you the readers who have made it here.

I hope you found this interesting and useful, if you intend to write plugins!

Also, the plugin itself has been useful to me, and hopefully other developers will make use of it too.

A bit on debugging

Kidding, I’m not done yet!!

I’ll finish this post with 2 debugging examples I’d encountered during the development of this plugin. Besides having somewhat funny conclusion (well, funny in my eyes :), they’re also good teaching for those who want to try working with GCC’s internals.

Runtime compiler errors

When writing code, you encounter compilation errors; plugins are no exception. You’ll also get runtime errors. But in compiler-related code, runtime errors have graver effects than usually expected: your code may seem to run fine, but if it has any erroneous behavior it might extend beyond the “run time” of your plguin - errors can be introduced into the (legit) code your plugin helps building!

I encountered some errors of this type during development. The most annoying one was as follows: compiling a small assert test program worked fine (that is, the assert rewriting code was alright); but when I compiled a bigger project with it, failing asserts would SIGSEGV in the rewritten assert logic.

How do we investigate this? You don’t have the crashing code… :) Because it’s generated by the plugin, duh. (Actually, I discovered later that you can get it - we’ll see how soon.)

A few words on the plugin, for context: due to some design decision I’d taken, it doesn’t generate printf calls directly, but instead generates code that collects the parts into a buffer (using an advancing sprintf, like pos += sprintf(buf + pos, ...)) then prints the buffer when done.

First thing I did was to take a stack trace of the runtime crash with GDB. It was in _IO_default_xsputn, called in the chain from sprintf. I followed the glibc code and crossed it with the faulting instruction, to realize that sprintf tried to write to a bad pointer.

Since it wasn’t deterministic (as I said, it only reproduced on some programs), I felt it has something to do with invalid use of memory (e.g using uninitialized memory). At this point I just read the generated assembly carefully and found the following: while the pos += sprintf(buf + pos, ...) looks alright, the memory location pos itself is never initialized to 0! I guess it worked on certain compilations - where, by chance/structure, the relevant stack position where pos is was already zero-initialized.

Why did it happen? In the plugin code I used DECL_INITIAL which lets you set the initial value for a DECL. I took this idea from some examples I found in the C frontend. Apparently I’ve been using it wrong, and it wasn’t initializing anything…

Finally I fixed it by using a MODIFY_EXPR to initialize the variable.

When I told my friend @sapir about this “bug”, he replied with this:

Great summary. Also, if someone out there manages to get this DECL_INITIAL working as expected, I’d be happy to hear…

By the way, a useful API that could help me here (had I known it that time) is print_generic_expr_to_str: this GCC function recreates back C code from GENERIC AST! Very cool. It can help you spot problems in your generated/modified AST, because it’s probably easier to read C code compared to longish debug_trees.

However, now that I’m writing this post, I wanted to try print_generic_expr_to_str and see if it could spot the problem for me. But sadly, the C code it generated for the buggy code did include the initialization of pos (it was written as signed long D.3000 = 0;, although the = 0 wasn’t existing in the generated assembly) So you should keep your doubt and check the assembly if things go bad :)

internal compiler error

Throughout plugin development, you’re gonna get “internal compiler error”s quite a lot. These are GCC’s way to tell you something got messed up. Sometimes their cause is clear: it might be a failing gcc_assert, reaching to gcc_unreachable and some other types of runtime checks.

And other times they’re like this one:

dummy.c:6:1: internal compiler error: Segmentation fault

In this case they are a nice name to “segmentation fault”, or in other words: your code led to some memory corruption / invalid access. Now, it might be in your code, and it might be somewhere deep inside GCC’s code (maybe your use of GCC’s API is incorrect). GCC produces a nice traceback that includes frames of plugin code, but it doesn’t include frames of GCC functions.

One of the crashes I had was in a call to build_function_call (the last frame in the stacktrace GCC gave me was the line in my plugin calling this function).

plugin_test.c:26:1: internal compiler error: Segmentation fault
   26 | }
      | ^
0x7faeb3f7a3d4 make_repr_sprintf
    /../gcc_assert_introspect/plugin.c:347
0x7faeb3f7ad57 make_conditional_expr_repr
    /../gcc_assert_introspect/plugin.c:496
...

(As of commit 0633d83b)

So the crash is somewhere in GCC… How can we debug these? What happened, and what was the full GCC stack trace?

Once again, GDB to the rescue. Now, simply running gdb gcc ... won’t do because the gcc command is actually a “driver program” that invokes other commands to do the real work of compiling/linking. The C compiler is cc1, and gcc forks then executes it. I used this example which tells GDB to follow the child process after GCC forks.

Ran with it and got a full stacktrace! Using backtrace, top of the stack was:

0x00000000008d12a7 in argument_parser::check_argument_type

GCC didn’t have source line information (well, I built this GCC I’ve been using, so blame on me):

$ addr2line -e ~/opt/gcc-9.1.0/bin/gcc 0x00000000008d12a7
??:0

Bummer :(

Onwards to the disassembly, then… The faulting code is:

   0x00000000008d1296 <+422>:   jle    0x60f878 <_ZN15argument_parser19check_argument_typeEPK16format_char_infoRK15length_modifierRP9tree_nodeRPKcbRmS8_iSA_SA_jc.part.0.cold+526>
   0x00000000008d129c <+428>:   mov    0x18(%rsp),%rcx
   0x00000000008d12a1 <+433>:   sub    $0x1,%eax
   0x00000000008d12a4 <+436>:   mov    (%rcx),%rdx
=> 0x00000000008d12a7 <+439>:   cmp    0x4(%rdx),%eax
   0x00000000008d12aa <+442>:   jae    0x60f88c <_ZN15argument_parser19check_argument_typeEPK16format_char_infoRK15length_modifierRP9tree_nodeRPKcbRmS8_iSA_SA_jc.part.0.cold+546>

rdx is dereferenced, but is was 0.

Names are mangled and the function went modifications during LTO (that’s the .part.0.cold suffix). So it took me a while to find the matching C++ code - line numbers would really help. If you build your GCC for development, make sure it has debug info!

That’s the faulting code (from check_format_types() in c-format.c):

if (EXPR_HAS_LOCATION (cur_param))
  param_loc = EXPR_LOCATION (cur_param);
else if (arglocs)
  {
    /* arg_num is 1-based.  */
    gcc_assert (types->arg_num > 0);
    param_loc = (*arglocs)[types->arg_num - 1];  // <----- CRASH IS HERE
  }

argloc is a vec (from gcc/vec.h). The faulting opcode, cmp 0x4(%rdx), %eax, is the bounds check before accessing the element at a given index (the check exists in builds with runtime checks). Thus rdx is *arglocs, which is NULL, while arglocs is not NULL. What?

Let’s walk the calls - from build_function_call to this point. So build_function_call calls c_build_function_call_vec with vNULL for arg_loc (vNULL is the “null” value for vecs). We get to build_function_call_vec which passes it to check_function_arguments as &arg_loc… And this value reaches our faulting code. Of course arglocs is not NULL! It’s the address of a parameter - it can never be NULL. But *arglocs is vNULL and it’s invalid to dereference it.

I believed this behavior is rather weird; and decided to send a question to the GCC mailing list, explaining the situation and asking if I did anything wrong, or this is a real problem I found here. Didn’t get any reply, so I filed an issue.

The issue got a reply pretty fast. One of the GCC developers said it’s not a bug because I wasn’t supposed to use build_function_call in the first place - it’s only used by the Objective-C/C++ frontends…

My fix was to create a wrapper for c_build_function_call_vec using non-vNULL arg_locs. Didn’t use build_call_expr, see here for an explanation.

Moral of the story? Try to use stuff from tree.h only. GCC has no explicit distinction between “plugin API”, “C frontend API” and other pieces of code. You can trust stuff from tree.h to be valid in virtually all cases; if you use any APIs declared in other files - make sure they are also used somewhere in the same frontend you’re working with: if writing something that works with the C frontend (like the plugin described in this article), don’t use functions that aren’t used anywhere in that frontend, otherwise it’s not unlikely you’ll bump into similar cases.

It was fun debugging, though :)

GCC Plugin Development Resources - part 2

We’ll finish, once again, with a collection of some references and tips for plugin developers.

Compile yourself a GCC version with some debug options enabled. Specifically I can vouche for --enable-checking of GCC’s configure: This enables many types of “tree check” macros which give proper messages before doing some invalid operation for a given type of node. Helps detecting when you misuse APIs. e.g it can change an internal compiler error: Segmentation fault to something nicer like internal compiler error: tree check: accessed operand 6 of ne_expr with 2 operands in .... I used this script to build, just make sure to add --enable-checking to the invocation of configure.
There’s gcc:<version> docker image in DockerHub, you can use it to easily test your plugin with different versions of GCC; docker run --rm -it gcc:7 /bin/bash. (Sadly, these were not built with debugging options ^^)
print_generic_expr_to_str generates back C code from a given GENERIC expression tree. Useful during development - you can print it along with debug_tree to see how certain expressions look.
Debugging GCC with some examples; Debugging hooks on cc1 in GDB.

Assert Rewriting - A GCC plugin - part 1

2020-04-25T12:31:04+00:00

This article tells the story of how I got into developing a GCC plugin that rewrites C asserts, in attempt to mimic py.test’s assert messages. It’s also a beginner’s guide to GCC plugin development.

The plugin itself is available here.

Poor man’s asserts

A few weeks ago I started working on a small side project in C, nothing too fancy. As with all new codebases, it was prone to many structural changes, API refactors etc. So I tried to add as many asserts as possible, and also wrote some basic C tests. When writing lots of new code, I try to have tests written ASAP, and fill the code with asserts since they help in quickly catching problems common to a developing codebase (like missed refactors / renames, misused APIs, …).

One thing I dislike about those asserts it that watching them fail usually doesn’t provide you with all the information necessary to fix the problem. A common assert like:

assert(n == 7);

will fail with:

main: main.c:6: main: Assertion `n == 7' failed.

telling you that n wasn’t 7, but not telling you what was the value n, which might be required to identify the reason of failure.

The problem gets worse when you have more complex expressions, like &&, || or function calls. So when an assert fails, I usually have to replace it with a printf of all expressions, recompile and rerun the failing code just so I could know what the problem was.

Back in that side project, after a session of about 10 “replace-assert-with-printf-then-rerun” changes, I thought there must be something I could do to improve it.

Then py.test popped into my mind. py.test is one of the most well-known Python test frameworks, and one of the features I like in it is that you write your tests logic using plain asserts, but unlike the standard Python assert failure (which raises an empty AssertionError), py.test prints a very elaborated assert failure message. For example, the following assert:

assert min([1, 2, 3]) - 5 + min(1, 2, 3) == max([5, 6, 5])

will fail with this exception:

>       assert min([1, 2, 3]) - 5 + min(1, 2, 3) == max([5, 6, 5])
E       assert ((1 - 5) + 1) == 6
E        +  where 1 = min([1, 2, 3])
E        +  and   1 = min(1, 2, 3)
E        +  and   6 = max([5, 6, 5])

That’s very cool. It would have been very useful if I had something similar in C. I decided to try and build that something, for my C code.

Adding introspection to asserts

I searched online and found this read, which gives a brief introduction on assert rewriting in py.test. The author (who wrote the feature in py.test) explains how subexpression information can be displayed by modifying the AST (Abstract Syntax Tree) of your test code.

If you’re not sure what’s AST, this image from Wikipedia will help. It shows the AST of a simple piece of code, written in its description. You can also take a look in AST explorer which provides online AST parsing of many languages (doesn’t have C though)

Python, being a dynamic language, allows you to modify the AST of modules during the loading process. py.test uses this to dismantle your asserts into smaller code pieces that are executed one by one. If any of them fails, the generated code is ready to print information about the exact point of failure.

Let’s see a simple, manual “assert rewriting” example. To gain introspection into:

assert n == 8 and myfunc() == 12

we can rewrite it as:

if n == 8:
    _tmp = myfunc()
    if _tmp == 12:
        # all good! the assert passed
        pass
    else:
        raise AssertionError("{0} != 12 (myfunc() = {0})".format(_tmp))
else:
    raise AssertionError("{0} != 8 (n = {0})".format(n))

As you can see, even for simple expressions it quickly becomes complex. For example, if any of the subexpressions has side-effects, it must be stored in a temporary variable (like _tmp) so we don’t invoke those side-effects multiple times. In the real world it gets even more complicated ;)

Lucky for us, this conversion is entirely automatic! py.test takes care of everything, and we get to write human-readable assert expressions.

Back to C

C is not a dynamic language. I can’t modify the AST of my program code in runtime. The compiler leaves you with machine instructions, it’s hard to extract accurate information about the original source code by messing with them in runtime.

Test frameworks in C need to provide useful failure message when test asserts fail to help you with debugging your tests, so they must do something more fancy than plain C asserts.

What’s common for them is to provide you a set of assert functions, suitable for all comparison types you may need. For example, the library Check has the following set of functions/macros (excerpt from src/check.in.h)

...
#define     ck_assert_int_eq(X, Y)   _ck_assert_int(X, ==, Y)
...
#define     ck_assert_int_ne(X, Y)   _ck_assert_int(X, !=, Y)
...
#define     ck_assert_int_lt(X, Y)   _ck_assert_int(X, <, Y)
...
#define     ck_assert_int_le(X, Y)   _ck_assert_int(X, <=, Y)
...

As you can see, you don’t write the expression X == Y but instead use ck_assert_int_eq with the arguments separated. _ck_assert_int can use the separated arguments to create a proper assert message:

#define _ck_assert_int(X, OP, Y) do { \
  intmax_t _ck_x = (X); \
  intmax_t _ck_y = (Y); \
  ck_assert_msg(_ck_x OP _ck_y, "Assertion '%s' failed: %s == %jd, %s == %jd", #X" "#OP" "#Y, #X, _ck_x, #Y, _ck_y); \
} while (0)

This produces useful messages, but the downside is that you have to remember all the ck_assert_* functions (the list is long), and write unintuitive code instead of a simple ==. If ck_assert_int_eq would accept the expression X == Y instead, it won’t have any introspection on the expression - it could only operate on the value of it.

This “problem” isn’t affecting Check only - in C, and in most other compiled languages, you don’t have access to the information required to parse your code’s own expression trees. You’ll need to be a part of the compilation process in order to get your hands on the AST. To be a part of the compilation process means, in most compiled languages, that you are required to be a part of the compiler, or a plugin of it.

Actually, Rust is the only language I know that lets your code intervene in it’s own compilation process, via procedural macros.

Update: Reddit comments mentioned Catch2, a C++ test framework which (among others) exploits operator precedence and overloading. Ultimately you have a macro REQUIRE(x == 5) and Catch2 can “parse” this expression to yeild similar results with respect to what I’m trying to achieve here. Not exactly AST parsing, but nonetheless it’s very cool so I thought it’s worth to mention here.

We’re in C, so… a GCC plugin it is.

GCC plugins intro

GCC provides an API for plugins. Plugins are programs built once, then loaded when invoking GCC. They can modify its behvaior, add new features, etc. More specifically, your plugin can register callbacks which GCC will call in different steps during compilation, allowing the plugin to mess around with GCC’s internal objects.

The GCC wiki has a short page with some background on plugins. It also lists some existing plugins, although the list isn’t so long. To get the hang of what plugins are capable of, here’s a brief on one of the GCC plugins the Linux kernel uses for its own build: named randstruct, this plugin randomizes the layout of structs during the kernel build process, so different kernel builds use different layout for their internal structs. This is an obfuscation, done to help in exploit mitigation. No way you could do that without a plugin - you’d have to change your code manually.

Into GCC

Here’s what I had in mind: I’ll write a plugin that “walks” over functions’ code, identifies calls to assert and rewrites them with code that’ll do all those nice printings. I didn’t stop to think how exactly this “code” is gonna work… I didn’t even bother looking in py.test’s implementation, though I wanted the plugin to produce similar messages.

So, GCC plugins. I had some experience writing those; a few months ago I wrote struct_layout. That plugin processes struct definitions as GCC encounters them, then dumps them in a specialized format.

I started by copying the plugin boilerplate from it. A plugin is basically a shared object which exports a plugin_init function. GCC calls it when the plugin is loaded, and your plugin can register callbacks for various compilation events using register_callback.

struct_layout registered on the event PLUGIN_FINISH_DECL, which is generated after finishing parsing a declaration. This time we need an event related to code parsing & AST. A quick look in plugin.def yields PLUGIN_PRE_GENERICIZE which is documented as allows to see low level AST in C and C++ frontends. Perfect!

The required prototype for the callback is void my_callback(void *event_data, void *user_data). user_data is a “private data” pointer (we can pass to register_callback and get it here), and event_data is the data itself: a tree object.

GCC trees

From the GCC docs:

The central data structure used by the internal representation is the tree.

Short enough, but it says a lot. Trees are a very central data structure, literally everything is represented by a tree object, and those can wield different types and properties. That “internal representation”, made of trees, creates the AST.

This article talks about the GCC internal representation called GENERIC. There’s another internal representation in GCC, named GIMPLE, but we won’t cover it here.

The AST is composed of multiple nodes; They can represent statements, declarations, types, … you get my point. We’re interested in reading functions. From my previous work on plugins, I remembered there’s a type of tree for representing functions: it’s called FUNCTION_DECL.

At this point I didn’t know what’s inside this FUNCTION_DECL tree. Plugin development guides are scarce, but after a bit of searching I found a nice guide giving concrete examples of AST nodes in GCC. I suggest you take a quick stop and read it (it’s short). At least take a look at the fancy diagrams.

Another useful document is GCC GENERIC docs where you can find a short paragraph on many (if not all?) tree types. I keept it open in one tab for the course of developemnt.

Plugin Basics

I think we know enough to start, let’s get some code running. Start by setting up your environment for plugin development. Some distros require the installation of a “GCC plugin dev” package (e.g Ubuntu), in others you get it in your standard GCC installation (e.g Arch)

For Ubuntu:

# You'll need gcc-X-plugin-dev, where X is your GCC major. check it with gcc --version.
# For Ubuntu 18.04 that will be:
$ sudo apt-get install gcc-7-plugin-dev

Let’s compile the empty plugin skeleton I described above. A minimal file is:

#include <stdio.h>

#include <gcc-plugin.h>
#include <tree.h>
#include <plugin-version.h>

int plugin_is_GPL_compatible; // must be defined & exported for the plugin to be loaded

static void pre_genericize_callback(void *event_data, void *user_data) {
    tree t = (tree)event_data;

    // ...
}

int plugin_init(struct plugin_name_args *plugin_info, struct plugin_gcc_version *version) {
    printf("Loaded! compiled for GCC %s\n", gcc_version.basever);
    register_callback(plugin_info->base_name, PLUGIN_PRE_GENERICIZE, pre_genericize_callback, NULL);

    return 0;
}

Write it to basic.c and build it:

$ g++ -g -I`gcc -print-file-name=plugin`/include -fpic -shared -o basic.so basic.c

The gcc -print-file-name=plugin prints the location where plugin headers are installed. We also compile with -fpic -shared to produce a shared library.

Now we’ll try to load it.

$ touch empty.c
$ gcc -fplugin=./basic.so empty.c -c
Loaded! compiled for GCC 9.1.0

Great. Now what do we do with that tree we have in our callback? It’s time to meet the single-handedly most useful debugging function you can use while developing for GCC: debug_tree. It accepts a tree object and dumps it recursively (to some depth), printing its type, its fields and descendants.

Add #include <print-tree.h> to the top, and change our callback function to this:

static void pre_genericize_callback(void *event_data, void *user_data) {
    tree t = (tree)event_data;

    debug_tree(t);
}

We’ll write a dummy function and compile it with the plugin active. -fplugin=/path/to/plugin.so tells GCC to load our plugin.

# start by recompiling the plugin
$ g++ -g -I`gcc -print-file-name=plugin`/include -fpic -shared -o basic.so basic.c
$ echo 'int dummy(int n) { return n + 5; }' > dummy.c
$ gcc -fplugin=./basic.so dummy.c -c

You should see something like::

 <function_decl 0x7f13df35be00 dummy
    type <function_type 0x7f13df263bd0
        type <integer_type 0x7f13df2525e8 int public SI
...

This is the AST node representing our function. A few words on the format:

Nodes (trees) begin with a < and end with a >.
Node type follows the <; Here we have function_decl, function_type and integer_type. Those types are themselves trees.
After the node type comes the node object addres in memory. It doesn’t convery much info, but it’s useful when comparing nodes because it tells you when two nodes are really equal (because they are the same object).
After the address comes an optional string describing the node. For declarations, it’s the name (our function_decl is named dummy). For types (such as integer_type) it’s the type name (here int).
The string before an opening < is the “name” of the field in the containing node. Here our function_decl has type of function_type, and function_type has type of integer_type.

Functions in the AST

I don’t see anything in the previous print about the function code, though! One of the diagrams in AST representation in GCC will be of help. It shows functions have a DECL_SAVED_TREE field, and gives usage example:

tree fnBody = DECL_SAVED_TREE (fnDecl);

The body is a tree itself, of course. So we can alter our debug_tree(t) to debug_tree(DECL_SAVED_TREE(t)).

Recompile the plugin, the recompile dummy.c with the plugin:

 <bind_expr 0x7fab614c3a80
    type <void_type 0x7fab6139bf18 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x7fab6139bf18
        pointer_to_this <pointer_type 0x7fab613a30a8>>
    side-effects
    body <return_expr 0x7fab614b1d40 type <void_type 0x7fab6139bf18 void>
        side-effects
        arg 0 <modify_expr 0x7fab614a0b90 type <integer_type 0x7fab6139b5e8 int>
            side-effects arg 0 <result_decl 0x7fab613911e0 D.1794>
            arg 1 <plus_expr 0x7fab614a0b68 type <integer_type 0x7fab6139b5e8 int>
                arg 0 <parm_decl 0x7fab614c4000 n>
                arg 1 <integer_cst 0x7fab613a03f0 constant 5>
                dummy.c:1:29 start: dummy.c:1:27 finish: dummy.c:1:31>
            dummy.c:1:29 start: dummy.c:1:27 finish: dummy.c:1:31>
        dummy.c:1:29 start: dummy.c:1:27 finish: dummy.c:1:31>
    block <block 0x7fab614a97e0 used
        supercontext <function_decl 0x7fab614a4e00 dummy type <function_type 0x7fab613acbd0>
            public static QI file dummy.c line 1 col 5 align 8 initial <block 0x7fab614a97e0> result <result_decl 0x7fab613911e0 D.1794> arguments <parm_decl 0x7fab614c4000 n>
            struct-function 0x7fab614c5000>>
    dummy.c:1:18 start: dummy.c:1:18 finish: dummy.c:1:18>

Lots of prints. Don’t get scared though, read and “parse” it slowly because everything here is logical. The function body is a bind_expr. What’s that? Head to the GENERIC docs and under Statements -> Blocks you’ll find a short explanation on BIND_EXPR:

Block scopes and the variables they declare in GENERIC are expressed using the BIND_EXPR code, ...

So a BIND_EXPR is just… Code and variables enclosed in { }. Very simple.

Note: debug_tree prints type names like bind_expr and field names like body in lowercase, but in the source code these are written in uppercase. From now on, I’ll be using the source notation, uppercase.

We can already see what the body contains, but let’s try getting the inner body tree first. Most tree types have special macros to access their fields; those can be found in gcc/tree.h. Time to grab a copy of the source!

When working with the source code of a project, I like having its Git available, so I can look up in the history, read commit messages, find out when a change was included into the mainline, etc. So I suggest you to clone GCC’s code: git clone https://github.com/gcc-mirror/gcc.git. You can also get the latest version only if you’re hasty: git clone --depth 1 https://github.com/gcc-mirror/gcc.git

By the way, we already have a local copy of tree.h and other API headers; We got them when we installed the plugin dev package. Nonetheless, having the full source code (including the implementation of things) is useful.

Open gcc/tree.h and search for “bind”. If possible, when searching for symbols, use symbolic search in this file since it’s utterly huge. I use Sublime, so Ctrl+R “bind” led me toBIND_EXPR_VARS, BIND_EXPR_BODY and BIND_EXPR_BLOCKS.

BIND_EXPR_BODY sounds like it. Let’s debug_tree it: debug_tree(BIND_EXPR_BODY(DECL_SAVED_TREE(t))).

 <return_expr 0x7fc48ba6fd40
    type <void_type 0x7fc48b959f18 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x7fc48b959f18
        pointer_to_this <pointer_type 0x7fc48b9610a8>>
    side-effects
    arg 0 <modify_expr 0x7fc48ba5eb90
        type <integer_type 0x7fc48b9595e8 int public SI
            size <integer_cst 0x7fc48b941f18 constant 32>
            unit size <integer_cst 0x7fc48b941f30 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0x7fc48b9595e8 precision 32 min <integer_cst 0x7fc48b941ed0 -2147483648> max <integer_cst 0x7fc48b941ee8 2147483647>
            pointer_to_this <pointer_type 0x7fc48b961a80>>
        side-effects
        arg 0 <result_decl 0x7fc48b94f1e0 D.1794 type <integer_type 0x7fc48b9595e8 int>
            ignored SI file dummy.c line 1 col 5 size <integer_cst 0x7fc48b941f18 32> unit size <integer_cst 0x7fc48b941f30 4>
            align 32 context <function_decl 0x7fc48ba62e00 dummy>>
        arg 1 <plus_expr 0x7fc48ba5eb68 type <integer_type 0x7fc48b9595e8 int>
            arg 0 <parm_decl 0x7fc48ba82000 n>
            arg 1 <integer_cst 0x7fc48b95e3f0 constant 5>
            dummy.c:1:29 start: dummy.c:1:27 finish: dummy.c:1:31>
        dummy.c:1:29 start: dummy.c:1:27 finish: dummy.c:1:31>
    dummy.c:1:29 start: dummy.c:1:27 finish: dummy.c:1:31>

Walk it top down:

RETURN_EXPR is explained in the GENERIC docs, Statements -> Basic Statements. Its first operand is the value to return, in our case a MODIFY_EXPR.
MODIFY_EXPR is explained under Expressions -> Unary and Binary Expressions: A MODIFY_EXPR, simply, is an assignment (includes assignments like += as well as =). Here its first operand is RESULT_DECL, which is a tree representing the return value of the current function - a value assigned to RESULT_DECL indicates it should be returned.
The second operand of the MODIFY_EXPR is a PLUS_EXPR: a simple + between its 2 operands.
The operands to our PLUS_EXPR are a PARM_DECL (represents a parameter to a function) and an INTEGER_CST which represents integer cosntants. The details displayed by debug_tree show us the PARM_DECL is named n, and the integer constant is 5.

Okay, we know how to read and parse out simple AST nodes! Now comes the question - is it possible to overwrite them during compilation? (Well, ealier I did say it’s possible… but let’s see how)

AST modifications

To replace a node with another one, we’ll need to create a new node first. Functions constructing new trees will begin with build, and tree.h has plenty of them. Most are not documented in tree.h itself but instead in their definition. My suggestion is that you try searching tree.h for keywords of what you need, it works quite well.

For our modification test - let’s modify the AST to make dummy return n + 10 instead of n + 5. So we need to replace the INTEGER_CST with another one, holding the value of 10.

Symbolic searching for “build int” yields build_int_cst. It accepts a “type” tree, and a value for the new const. The “type” may be the tree representing the C type int, the C type long, etc. All those common types are declared in tree.h. We will use integer_type_node for a plain int.

In tree.h we’ll also find TREE_OPERAND(NODE, I), which accesses the I’th operand of a node. This way we can walk down the expression tree until we get to the node we wish to replace.

static void pre_genericize_callback(void *event_data, void *user_data) {
    tree t = (tree)event_data;

    tree body = BIND_EXPR_BODY(DECL_SAVED_TREE(t));
    tree modify = TREE_OPERAND(body, 0);
    tree plus = TREE_OPERAND(modify, 1);
    // replace it! (TREE_OPERAND's result is an lvalue)
    TREE_OPERAND(plus, 1) = build_int_cst(integer_type_node, 10);
}

Recompile the plugin, recompile dummy.c with the plugin, and write another simple file main.c:

#include <stdio.h>

int dummy(int n);

int main(void) {
    printf("%d\n", dummy(1));
    return 0;
}

Build (this time without the plugin):

$ gcc main.c dummy.o -o main  # note: use the dummy.o compiled with the plugin, not dummy.c!

And…

$ ./main
11

Worked! Hooray.

You can compile dummy.c again without the plugin to see the difference:

$ gcc main.c dummy.c -o main  # dummy.c this time
$ ./main
6

And that concludes it for this post.

I actually intended to focus on the assert rewriting part, but ended up talking about GCC for the most part. I’m happy it came out this way, though - by this guide I wish to provide smoother entry to plugin development for everyone. During my career as a developer I have spent many hours reading GCC’s user docs, searching for the right compiler flag for a task, etc. Gaining insight in the internals, being able to extend C & GCC with features I couldn’t have earlier - well, it was very nice, and I think every developer should try it sometime :)

In the next part, we’ll talk about the assert rewriting logic itself, and how to embed it in the AST via the plugin. We’ll also dive deeper into GCC and GENERIC representation.

GCC Plugin Development Resources

I collected here the references I gave through the article. Many we useful for me during this project, some I found only afterwards. Anyway, all are useful and thus I put them here together so future plugin developers can use them.

AST representation in GCC - AST in GCC trees.
GCC GENERIC trees - the official docs for tree types.
Understanding Trees - in GCC wiki, short but contains useful examples.
Playing with GCC plugins - simple plugin that logs structs’ sizes. Insipired me to try plugins.
A simple plugin for GCC - implements the warn_unused_result attribute correctly for C++. That guide works with GIMPLE, not with GENERIC as I did here, but some parts are common and nonetheless it’s an interesting read.
GCC tiny, by the same author of the previous entry - writing a new GCC front end for a simple language. Based on GENERIC. Very comprehensive.
This guide itself :) And its future parts, in days to come…