Support targeting function declarations/headers with -fplugin-arg-instrument_attribute-include-file-list

[christophebedard]

Currently, it seems that providing a (partial) path to header files, i.e. files with function declarations, as opposed to definitions, with -fplugin-arg-instrument_attribute-include-file-list doesn't work. We need to point to files with function definitions instead (i.e. source files).

This is probably due to these lines:

instrument-attribute-gcc-plugin/src/instrument_attribute.c

Lines 127 to 128 in 546adcd

	// Make sure it's a function
	if (FUNCTION_DECL == TREE_CODE(fndecl)) {

One would think that FUNCTION_DECL refers to the function declaration, but I guess not. I've been looking at the gcc plugin headers, but I don't know most of the terminology.

[christophebedard]

We need to register a callback with PLUGIN_FINISH_DECL instead of PLUGIN_FINISH_PARSE_FUNCTION to process #included headers/function declarations (including system headers): https://github.com/gcc-mirror/gcc/blob/d64584d2fbe79b34e7176681a9d9f85851628ce8/gcc/plugin.def#L32-L33

However, even if the instrumentation gets enabled following a match with a function declaration in a header file, when the function definition gets processed, instrumentation will be disabled unless there is also a match. For example, this means that we would need to either just use -fplugin-arg-instrument_attribute-include-function-list or use -fplugin-arg-instrument_attribute-include-file-list with (sub)paths that match the header and the source file. This kind of defeats the purpose.

We would need a separate flag or way to know that we have already decided to instrumentation a given function so that we don't disable the instrumentation later on. There might be a way to keep track of this using some sort of hash table, but it starts getting weird a bit and would probably affect performance.

[christophebedard]

Until a proper solution is found, this should be properly documented in the README.