This is the mail archive of the
mailing list for the GCC project.
Re: Understand GCC test process
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Sabrina Souto <sabrinadfs at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 7 Oct 2015 17:23:16 +0100
- Subject: Re: Understand GCC test process
- Authentication-results: sourceware.org; auth=none
- References: <CAA1wpi1MCPPBqmr2iCKmpdiG5gu5zL=MOAx+y1cEtfzxkMajLg at mail dot gmail dot com> <CAH6eHdSaqsn8xDSG46GwMvgVjGOoRoPtkXC5t+AbAvg=_jkkkA at mail dot gmail dot com> <CAA1wpi3y_SO8s_pjaZS-fC6GgfkuDCOnnaQNurDJkZi1kqJY7w at mail dot gmail dot com> <CAH6eHdTwhgLHWQhsdrB9ZUX3=LD3m-m=hBGXswmyT0c2+c5DHQ at mail dot gmail dot com> <CAA1wpi22TZ=awDNWRBtechjamK+T+Z3LiB7GnsnXO1sdMUxp2w at mail dot gmail dot com> <CAH6eHdQhBsu6BfRFpikXEeBsvN=fV9O16ytp-Vb41ke++Zt_iQ at mail dot gmail dot com> <CAA1wpi0om0ZoFPopu0j4YmGM_iFNM4H8-2NwKunu2Ta-SEHuRA at mail dot gmail dot com>
On 7 October 2015 at 16:45, Sabrina Souto <email@example.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.