On 7 October 2015 at 16:45, Sabrina Souto <sabrina...@gmail.com> wrote: >> What exactly are you tracing, and how? > I'm proposing an approach for testing configurable system in my > research, and I'm trying to apply it to GCC. So, I instrumented the > GCC function calls (in the first level of ..gcc-version-x.x/gcc/ and > the dirs related to C/C++) and some options, in a semi-automatic way > (I tried to use PIN, but it was very slow...). > >> Are you only tracing the 'gcc' driver? Or every process and child >> process that gets spawned by 'make'? > I'm tracing the 'gcc' driver.
OK, all that does is process some options and then call another executable, which does the actual compilation. To compile C code it calls cc1, to compile C++ code it calls cc1plus etc. So if you're only tracing the 'gcc' driver then you are basically only tracing the code for parsing command-line arguments and choosing which compiler to execute. >> >> Typically to run the testsuite you run 'make', which runs DejaGnu's >> 'runtest' shell script, which runs the 'expect' program (written in >> Tcl), which invokes the 'gcc' driver, which invokes the actual >> compiler, 'cc1', to compile a testcase. So a lot of that is common to >> every testcase. > Do you mean, for example, that the compiler will always build the AST, > translate to intermediary code representations, etc., regardless of > the compilation option... and it corresponds to a lot of common code > across all tests? No, for example if it is run with -E it will only do preprocessing. But you're not tracing the compiler anyway. The 'gcc' executable is not the compiler.
