LWN: Comments on "An introduction to creating GCC plugins"

An introduction to creating GCC plugins

Patosga — Fri, 03 Mar 2017 22:38:36 +0000

Hi,

I'm interested on assessing memory accesses on a C program.
I want to generate my own code for all write operations to a specific variable, which is identified by the name.

Do you have any idea how I could achieve that? Or where should I start?

You said you can traverse the abstraction layers by getting an SSA_NAME instance and then a POINTER_TYPE, etc...
Is it possible to be at the lowest abstraction level (RTL I think) and identify write operations on a specific variable, just before the assembly code is generated?

Thanks!

An introduction to creating GCC plugins

milly_Z — Sat, 27 Feb 2016 02:23:47 +0000

Thank you very much. I've been successful to build .so file, but something went wrong later.
$SPELLER=/home/yancai/Research/gcc-plugin/myplugin/speller.so

If I use gcc-4.6, terminal showed as following:

yancai@yancai-ThinkPad-W541:~/Research/gcc-plugin/myplugin$ gcc -fplugin=$SPELLER test.c
cc1: error: cannot load plugin /home/yancai/Research/gcc-plugin/myplugin/speller.so
/home/yancai/Research/gcc-plugin/myplugin/speller.so: undefined symbol: to_aspell_speller

Well, I've found that symbol in aspell.h.

Then I changed to gcc-4.7, and terminal showed as following:

yancai@yancai-ThinkPad-W541:~/Research/gcc-plugin/myplugin$ gcc -fplugin=$SPELLER test.ccc1: 错误：无法加载插件 /home/yancai/Research/gcc-plugin/myplugin/speller.so
/home/yancai/Research/gcc-plugin/myplugin/speller.so: undefined symbol: warning_at

I followed the tips above, using g++ (mine is 4.8), and terminal showed as following:

yancai@yancai-ThinkPad-W541:~/Research/gcc-plugin/myplugin$ g++ -I/usr/lib/gcc/i686-linux-gnu/4.8/plugin/include -c -fPIC -o speller.o speller.c
speller.c:165:5: error: expected primary-expression before ‘.’ token
.pass.type = GIMPLE_PASS,
^
speller.c:166:5: error: expected primary-expression before ‘.’ token
.pass.name = "speller", /* For use in the dump file */
^
speller.c:167:5: error: expected primary-expression before ‘.’ token
.pass.gate = speller_gate,
^
speller.c:168:5: error: expected primary-expression before ‘.’ token
.pass.execute = speller_exec, /* Pass handler/callback */
^

Um...I really don't know what should I do next and I need some help.
Thank you very much.

An introduction to creating GCC plugins

cortana — Fri, 26 Feb 2016 12:44:23 +0000

You need to install the aspell development files. Exactly how you do this depends on which distribution you're using. If you're using Debian (or some Debian-derived distribution such as Ubuntu) then you can use http://packages.debian.org/file:/usr/include/aspell.h to see which package contains the missing file, and then install it with 'apt-get install libaspell-dev'.

An introduction to creating GCC plugins

milly_Z — Fri, 26 Feb 2016 12:37:09 +0000

Hi,
I am beginner in gcc plugins. I copied the source codes, but I failed to build the shared object. Terminal showed as following:
yancai@yancai-ThinkPad-W541:~/Research/gcc/myplugin$ gcc -I/usr/lib/gcc/i686-linux-gnu/4.6/plugin/include -c -fPIC -o speller.o speller.c
speller.c:22:20: fatal error: aspell.h: no such file or directory
compilation terminated.

Could you please help me solve the problem?

Thanks,
milly

An introduction to creating GCC plugins

milly_Z — Fri, 26 Feb 2016 12:13:11 +0000

Could you please tell me how did you succeeded in that?

Thanks,
milly

An introduction to creating GCC plugins

PaXTeam — Mon, 17 Jun 2013 21:28:19 +0000

gcc 4.7 introduced the ability to be built with a c++ compiler and most/all distros build gcc that way so you'll have to build your plugins with g++ instead of gcc as well.

An introduction to creating GCC plugins

sandeepchaudhary — Mon, 17 Jun 2013 21:04:06 +0000

Hi guys,

I am posting this comment here for some help. I have followed the steps mentioned in this tutorial to create the plugin, and I am able to successfully build the plugin shared object. However, I can not run the plugin. It gives errors related to undefined symbols. Below is the terminal snippet.

sandeep@ubuntu:~/myplugin$ /usr/bin/gcc -fplugin=/home/sandeep/myplugin/speller.so -c test.c
cc1: error: cannot load plugin /home/sandeep/myplugin/speller.so
/home/sandeep/myplugin/speller.so: undefined symbol: warning_at

I can see that the mentioned symbol is indeed undefined using following

sandeep@ubuntu:~/myplugin$ nm -D -C speller.so | grep warning_at
U warning_at

And I see that

sandeep@ubuntu:/usr/lib/gcc/x86_64-linux-gnu/4.7.2$ pwd
/usr/lib/gcc/x86_64-linux-gnu/4.7.2
sandeep@ubuntu:/usr/lib/gcc/x86_64-linux-gnu/4.7.2$ nm -D -C $(gcc -print-file-name=cc1) | grep "warning_"
0000000000c1e5a0 T warning_at(unsigned int, int, char const*, ...)

What am I missing? How should I link the libraries correctly?

Thanks,
Sandeep.

An introduction to creating GCC plugins

MattDavis — Tue, 04 Oct 2011 08:44:38 +0000

Thanks for the tip!

An introduction to creating GCC plugins

PaXTeam — Fri, 30 Sep 2011 21:10:25 +0000

i assume you're compiling all your code with -O0 then lest you fall victim of the infamous NULL check elimination as the kernel itself did not long ago, not to mention SSP that must be your enemy #1 then ;). more seriously, and assuming you're talking about the constification plugin, the truth is that the patch route was tried before and it just doesn't scale at both the producer (patch writer) and the consumer (lkml/kernel devs) side.

to give you some numbers, an allmodconfig 2.6.39 i386 kernel loses over 7000 static (i.e., not runtime allocated) writable function pointers (a reduction of about 16%). creating an equivalent source patch would be thousands of lines of code and have virtually no chance to be accepted in any reasonable amount of time (not to mention the maintenance effort of being out-of-tree during the process; i've carried a small fraction of such a patch in PaX for years and it was a PITA even if the patch itself was 'only' 800k).

also by virtue of enforcing const on these types one will quickly find out all the places where variables of a given type are modified (sometimes in direct contradiction to kernel policy) and one will be forced to document it in the code (for each such exception there's a writable type to be used, based on the no_const attribute introduced by the plugin). the patch for this is about 100k, but it also includes changes that actually eliminate the need to modify a given variable (vs. just changing its type to be writable).

all in all, the cost/benefit ratio of the plugin approach is excellent and there's a lot more in the pipeline ;).

An introduction to creating GCC plugins

vonbrand — Fri, 30 Sep 2011 13:38:00 +0000

I'd vote for a way to point out such oportunities to hackers, or even write source patches. Some magic mangling that gives object code that doesn't behave as the source says is deeply disturbing to my little mind.

An introduction to creating GCC plugins

PaXTeam — Thu, 29 Sep 2011 21:58:56 +0000

if anyone's interested in what gcc plugins can do in a kernel context, check out the few distributed in PaX (under tools/gcc). some examples: automatic ops structure constification, user/kernel function pointer separation, *alloc size statistics, etc.

An introduction to creating GCC plugins: also GCC MELT or GCC Python

dave_malcolm — Thu, 29 Sep 2011 20:19:53 +0000

Thanks for mentioning the gcc Python plugin.

I'm the author of the Python plugin, so naturally I'm fond of it.

The lack of pattern matching within Python's syntax hasn't been a major issue to me in practice. Also, I like to think that it's become significantly more mature than when I first announced it :)

I suspect that MELT will lead to faster-executing results, given that CPython isn't the fastest runtime in the world - though speed hasn't been an issue for me yet, either.

Inspired by this LWN article, I had a go at implementing a spell-checking GCC pass in Python, using my plugin.

You can see the results at:
http://readthedocs.org/docs/gcc-python-plugin/en/latest/w...

I believe my version is considerably simpler than doing it in C (about 35 lines of Python code, including comments), and, I hope, easier to read.

The Python implementation of the spell checker is slightly different to the one in the article, in that I'm using gcc.Gimple.walk_tree() on each statement to (recursively) visit all tree nodes it references. I'm also using gcc.warning() and gcc.inform() to integrate with GCC's warnings subsystem, so that the error messages are in GCC's normal format (so that e.g. when I click on them in emacs it takes me to the source line containing the error).

One of the nice things about using Python for this is all of the 3rd-party libraries that are available. In the Python implementation I'm using the "enchant" module that came out of AbiWord's spellchecker, and this makes it easy to offer spelling suggestions. There is a huge collection of Python libraries out there, so if you want to e.g. pause compilation part-way through and serve the internal-representation over HTTP, or dump it all into a database etc, there are lots of possibilities there.

Hope this is helpful
Dave

source code for example

corbet — Thu, 29 Sep 2011 13:27:28 +0000

Over here. It was linked from the article, though, I must admit, not in an easy-to-notice way.

source code for example

mjw — Thu, 29 Sep 2011 09:04:05 +0000

Is the source code for this example plugin available for those of us who are too lazy to copy/paste from the article?

An introduction to creating GCC plugins: also GCC MELT or GCC Python

bstarynk — Thu, 29 Sep 2011 06:42:54 +0000

There are also some simpler way to extend GCC: coding GCC plugins in C is tedious, and there are some alternatives:

First, use GCC-MELT (disclaimer: I, Basile, am the main author of GCC MELT). MELT is a high-level domain specific language to ease the development of GCC extensions. The MELT language provides some high-level features: ability to do powerful pattern matching on GCC internal data (like Gimple): first-class dynamically typed garbage-collected values; ability to add new GCC passes in MELT; the MELT language is translated to C, and you can even add small C code chunks in your MELT code; MELT has a syntax similar to Lisp or Scheme; your MELT extensions can analyze or modify GCC internal representations, for various tasks like static analysis, coding rules validation, specific warnings, optimization, code refactoring, etc. MELT is available as a GCC [meta-] plugin.
There is also a Gcc Python Plugin which enables you to code your GCC plugin-like extensions in Python. However, Python don't give you pattern matching on GCC internal representations (like MELT does), and the GCC Python plugin is less mature than MELT so gives you access to less internal GCC data.

The main point is that people should consider extending GCC for their own needs and this is now possible with GCC plugin machinery, either in C, or in MELT or Python.

-- Basile Starynkevitch