I was seeing these files but I could not put the puzzle pieces
together in my mind, and after you explained, all pieces make sense
now. Thanks for the explanation, Jonathan.
The testing process is clear now, but I still not understanding what
can explain that amount of common functions (over 60%) across all
traces of the tests (that I analyzed) from gcc.dg test suite, could
you help me with this? I have some hypotheses:
(1) All tests run the compiler and there is a large "core" code that
is executed regardless of the compiler option?
(2) Since all tests run the same driver - dg.exp, I could say that
this great amount of common functions is due to what is specified in
the driver, and the remaining few different functions are related with
the particularity of each test?
(3) None of those. Do you have another explanation?
Thanks,
On Wed, Oct 7, 2015 at 10:22 AM, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 7 October 2015 at 14:03, Sabrina Souto wrote:
>>>> Hi,
>>>> I'm needing to analyze the execution flow of a test, but don't
>>>> understand how the test drivers, e.g., gcc-dg.exp or dg.exp, access
>>>> the source code of GCC. When a test starts, what is the first function
>>>> that is called? How can I know that?
>>>
>>> The first function is main(), because the tests just run the compiler.
>>> DejaGnu doesn't access the source code of GCC, it just runs the
>>> compiler executable.
>>
>> OK, I understand. But when a test run the compiler, all compiler
>> stages/phases are always executed?
>
> No, only the stages requested by the dg-do directive.
>
>> how the test knows the compiler
>> stage must be run? from the "dg-do" actions (preprocess, compile,
>> assemble, link, run)? how the "dg-do" actions are processed/performed?
>
> That's initially handled by DejaGnu, not GCC. See the site-wide dg.exp
> file (on my system that is /usr/share/dejagnu/dg.exp) which says:
>
> # dg-do do-what-keyword [{ target/xfail selector }]
> # `do-what-keyword' is tool specific and is passed unchanged to
> # ${tool}-dg-test. An example is gcc where `keyword' can be any of:
> # preprocess|compile|assemble|link|run
> # and will do one of: produce a .i, produce a .s, produce a .o,
> # produce an a.out, or produce an a.out and run it (the default is
> # compile).
>
> So that passes the argument to the callback gcc-dg-test, which is
> defined in gcc/testsuite/lib/gcc-dg.exp, and that sets the
> 'compile_type' variable to one of assemble, preprocess, link etc. and
> sets the appropriate output filename for the action.
>
> That is then translated into command-line options for the compiler, so
> a 'compile' test will be run with -c, an 'assemble' test will be run
> with -S, a 'link' test will have no special option (so all stages run)
> and a 'run' test does the same as 'link' but also runs the executable.
--
Sabrina Souto
