This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

DECL_STRUCT_FUNCTION(cgraphnode->decl) == NULL when attempting Link-Time Optimization in plugin


I'm working on a static analysis extension to GCC via my
gcc-python-plugin [1]

The analysis is interprocedural (memory leak detection, as it happens).
I have it working on one translation unit at a time, and I'm attempting
to get it to work within Link Time Optimization so that it can see the
interactions of all of the functions within a program or library, but
I'm running what might be a bug (or I could be misunderstanding LTO).

I have my plugin working within lto1, using "-flto" and "-fplugin"; my
command line looks like:
$ gcc -fPIC -shared -flto -g
-fplugin=/home/david/coding/gcc-python/gcc-python/sm/python.so
-fplugin-arg-python-script=examples/show-lto-supergraph.py
tests/sm/lto/input-*.c --save-temps

lto1 appears to be invoked twice by gcc.  The first time, there are two
passes:
 IPA_PASS named "whole-program"
 IPA_PASS named "inline"
and "in_lto_p" is true.

The second invocation has these passes, called per-function:
  GIMPLE_PASS "*free_cfg_annotations"
  GIMPLE_PASS "cplxlower0"
  GIMPLE_PASS "optimized"
  RTL_PASS "expand"
  GIMPLE_PASS "*rest_of_compilation"
  RTL_PASS "*init_function"
  ...etc.., normal rest of compilation from RTL stage onwards
and "in_lto_p" is false.

I've attempted to wire in my interprocedural analysis as a new IPA pass
before or after "whole-program" and "inline" within the first invocation
of lto1.  In each case it is able to walk the callgraph, and the
callgraph it sees appears to be correct: walking the linked list of
cgraph_nodes the various cgraph_edge and cgraph_node are as expected,
and for each cgraph_node, cgraph_node->decl is a non-NULL tree instance
of type FUNCTION_DECL (as expected); I'm able to generate a graphviz
rendering of the whole-program callgraph within lto1 from my plugin.

However, for every cgraph_node, the
DECL_STRUCT_FUNCTION(cgraph_node->decl) is (struct function*)NULL, which
thwarts my code's attempt to look up the CFG of each underlying function
and work on the underlying gimple.

Looking with eu-readelf at the .o files shows these lto sections are
present ("f" is the name of one of the functions that I'd like to access
the gimple CFG of):
$ eu-readelf -a input-f.o|grep lto
[ 5] .gnu.lto_.inline.c8904cb9a96e7417 PROGBITS     0000000000000000 0000006c 00000026  0 E      0   0  1
[ 6] .gnu.lto_f.c8904cb9a96e7417 PROGBITS     0000000000000000 00000092 00000164  0 E      0   0  1
[ 7] .gnu.lto_.cgraph.c8904cb9a96e7417 PROGBITS     0000000000000000 000001f6 00000032  0 E      0   0  1
[ 8] .gnu.lto_.vars.c8904cb9a96e7417 PROGBITS     0000000000000000 00000228 00000012  0 E      0   0  1
[ 9] .gnu.lto_.refs.c8904cb9a96e7417 PROGBITS     0000000000000000 0000023a 00000013  0 E      0   0  1
[10] .gnu.lto_.statics.c8904cb9a96e7417 PROGBITS     0000000000000000 0000024d 00000014  0 E      0   0  1
[11] .gnu.lto_.decls.c8904cb9a96e7417 PROGBITS     0000000000000000 00000261 000001f3  0 E      0   0  1
[12] .gnu.lto_.symtab.c8904cb9a96e7417 PROGBITS     0000000000000000 00000454 00000011  0 E      0   0  1
[13] .gnu.lto_.opts       PROGBITS     0000000000000000 00000465 000000e9  0 E      0   0  1
   25: 0000000000000001      1 OBJECT  GLOBAL DEFAULT   COMMON __gnu_lto_v1
  [    2a]  __gnu_lto_v1

Are the (struct function*) and CFG meant to exist at this stage, and be
in gimple form, and is DECL_STRUCT_FUNCTION meant to be non-NULL for
functions in translation units that were compiled with -flto?  (or have
I misunderstood LTO?)

This is gcc 4.7 on Fedora 17, specifically gcc-4.7.0-5.fc17.x86_64

Thanks
Dave
[1] https://fedorahosted.org/gcc-python-plugin/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]