Showing posts with label gcc. Show all posts
Showing posts with label gcc. Show all posts

Friday, January 11, 2013

How to tweak CFLAGS globally when configure is in use, such as a gcc build

I plan to use this to pass down "-save-temps=obj" to force temporary assembly files to be preserved in a place where they can be found for reference.  Wish me luck (or tell me where I go astray)!  :-)    C.
----------------------------------------------------------------------------------------
config.site - automake: "2.2.5 Overriding Default Configuration Setting with config.site

When installing several packages using the same setup, it can be convenient to create a file to capture common settings. If a file named prefix/share/config.site exists, configure will source it at the beginning of its execution.

Recall the command from the previous section:

~/amhello-1.0 % ./configure --prefix ~/usr CC=gcc-3 \
CPPFLAGS=-I$HOME/usr/include LDFLAGS=-L$HOME/usr/lib
Assuming we are installing many package in ~/usr, and will always want to use these definitions of CC, CPPFLAGS, and LDFLAGS, we can automate this by creating the following ~/usr/share/config.site file:

test -z "$CC" && CC=gcc-3
test -z "$CPPFLAGS" && CPPFLAGS=-I$HOME/usr/include
test -z "$LDFLAGS" && LDFLAGS=-L$HOME/usr/lib
Now, any time a configure script is using the ~/usr prefix, it will execute the above config.site and define these three variables.

~/amhello-1.0 % ./configure --prefix ~/usr
configure: loading site script /home/adl/usr/share/config.site
...
See Setting Site Defaults, for more information about this feature."

Also, thanks to this site for the following:
http://stackoverflow.com/questions/7561509/how-to-add-include-and-lib-paths-to-configure-make-cycle

" You want a config.site file. Try:
$ mkdir -p ~/local/share
$ cat << EOF > ~/local/share/config.site
CPPFLAGS=-I$HOME/local/include
LDFLAGS=-L$HOME/local/lib
...
EOF 
Whenever you invoke an autoconf generated configure script with --prefix=$HOME/local, the config.site will be read and all the assignments will be made for you. CPPFLAGS and LDFLAGS should be all you need, but you can make any other desired assignments as well (hence the ... in the sample above). Note that -I flags belong in CPPFLAGS and not in CFLAGS, as -I is intended for the pre-processor and not the compiler."

'via Blog this'

Tuesday, December 11, 2012

Conditional Parts of Makefiles, Gnu Make, courtesy of mit.edu

I found it hard to understand in detail the exact legal syntax of  the Makefile conditionals, and the code that goes inside of them, and this was the clearest explanation I found on the web.

Conditional Parts of Makefiles

A conditional causes part of a makefile to be obeyed or ignored depending on the values of variables. Conditionals can compare the value of one variable to another, or the value of a variable to a constant string. Conditionals control what make actually "sees" in the makefile, so they cannot be used to control shell commands at the time of execution.

Example of a Conditional

The following example of a conditional tells make to use one set of libraries if the CC variable is `gcc', and a different set of libraries otherwise. It works by controlling which of two command lines will be used as the command for a rule. The result is that `CC=gcc' as an argument to make changes not only which compiler is used but also which libraries are linked.

libs_for_gcc = -lgnu
normal_libs =

foo: $(objects)
ifeq ($(CC),gcc)
        $(CC) -o foo $(objects) $(libs_for_gcc)
else
        $(CC) -o foo $(objects) $(normal_libs)
endif
This conditional uses three directives: one ifeq, one else and one endif.
The ifeq directive begins the conditional, and specifies the condition. It contains two arguments, separated by a comma and surrounded by parentheses. Variable substitution is performed on both arguments and then they are compared. The lines of the makefile following the ifeq are obeyed if the two arguments match; otherwise they are ignored.
The else directive causes the following lines to be obeyed if the previous conditional failed. In the example above, this means that the second alternative linking command is used whenever the first alternative is not used. It is optional to have an else in a conditional.
The endif directive ends the conditional. Every conditional must end with an endif. Unconditional makefile text follows.
As this example illustrates, conditionals work at the textual level: the lines of the conditional are treated as part of the makefile, or ignored, according to the condition. This is why the larger syntactic units of the makefile, such as rules, may cross the beginning or the end of the conditional.
When the variable CC has the value `gcc', the above example has this effect:

foo: $(objects)
        $(CC) -o foo $(objects) $(libs_for_gcc)
When the variable CC has any other value, the effect is this:

foo: $(objects)
        $(CC) -o foo $(objects) $(normal_libs)
Equivalent results can be obtained in another way by conditionalizing a variable assignment and then using the variable unconditionally:

libs_for_gcc = -lgnu
normal_libs =

ifeq ($(CC),gcc)
  libs=$(libs_for_gcc)
else
  libs=$(normal_libs)
endif

foo: $(objects)
        $(CC) -o foo $(objects) $(libs)

Syntax of Conditionals

The syntax of a simple conditional with no else is as follows:

conditional-directive
text-if-true
endif
The text-if-true may be any lines of text, to be considered as part of the makefile if the condition is true. If the condition is false, no text is used instead.
The syntax of a complex conditional is as follows:

conditional-directive
text-if-true
else
text-if-false
endif
If the condition is true, text-if-true is used; otherwise, text-if-false is used instead. The text-if-false can be any number of lines of text.
The syntax of the conditional-directive is the same whether the conditional is simple or complex. There are four different directives that test different conditions. Here is a table of them:

ifeq (arg1, arg2)
ifeq 'arg1' 'arg2'
ifeq "arg1" "arg2"
ifeq "arg1" 'arg2'
ifeq 'arg1' "arg2"
Expand all variable references in arg1 and arg2 and compare them. If they are identical, the text-if-true is effective; otherwise, the text-if-false, if any, is effective.Often you want to test if a variable has a non-empty value. When the value results from complex expansions of variables and functions, expansions you would consider empty may actually contain whitespace characters and thus are not seen as empty. However, you can use the strip function (see section Functions for String Substitution and Analysis) to avoid interpreting whitespace as a non-empty value. For example:
ifeq ($(strip $(foo)),)
text-if-empty
endif
will evaluate text-if-empty even if the expansion of $(foo) contains whitespace characters.
ifneq (arg1, arg2)
ifneq 'arg1' 'arg2'
ifneq "arg1" "arg2"
ifneq "arg1" 'arg2'
ifneq 'arg1' "arg2"
Expand all variable references in arg1 and arg2 and compare them. If they are different, the text-if-true is effective; otherwise, the text-if-false, if any, is effective.
ifdef variable-name
If the variable variable-name has a non-empty value, the text-if-true is effective; otherwise, the text-if-false, if any, is effective. Variables that have never been defined have an empty value.Note that ifdef only tests whether a variable has a value. It does not expand the variable to see if that value is nonempty. Consequently, tests using ifdef return true for all definitions except those like foo =. To test for an empty value, use ifeq ($(foo),). For example,
bar =
foo = $(bar)
ifdef foo
frobozz = yes
else
frobozz = no
endif
sets `frobozz' to `yes', while:
foo =
ifdef foo
frobozz = yes
else
frobozz = no
endif
sets `frobozz' to `no'.
ifndef variable-name
If the variable variable-name has an empty value, the text-if-true is effective; otherwise, the text-if-false, if any, is effective.
Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed. (If the line begins with a tab, it will be considered a command for a rule.) Aside from this, extra spaces or tabs may be inserted with no effect anywhere except within the directive name or within an argument. A comment starting with `#' may appear at the end of the line.
The other two directives that play a part in a conditional are else and endif. Each of these directives is written as one word, with no arguments. Extra spaces are allowed and ignored at the beginning of the line, and spaces or tabs at the end. A comment starting with `#' may appear at the end of the line.
Conditionals affect which lines of the makefile make uses. If the condition is true, make reads the lines of the text-if-true as part of the makefile; if the condition is false, make ignores those lines completely. It follows that syntactic units of the makefile, such as rules, may safely be split across the beginning or the end of the conditional.
make evaluates conditionals when it reads a makefile. Consequently, you cannot use automatic variables in the tests of conditionals because they are not defined until commands are run (see section Automatic Variables).
To prevent intolerable confusion, it is not permitted to start a conditional in one makefile and end it in another. However, you may write an include directive within a conditional, provided you do not attempt to terminate the conditional inside the included file.

Conditionals that Test Flags

You can write a conditional that tests make command flags such as `-t' by using the variable MAKEFLAGS together with the findstring function (see section Functions for String Substitution and Analysis). This is useful when touch is not enough to make a file appear up to date.
The findstring function determines whether one string appears as a substring of another. If you want to test for the `-t' flag, use `t' as the first string and the value of MAKEFLAGS as the other.
For example, here is how to arrange to use `ranlib -t' to finish marking an archive file up to date:

archive.a: ...
ifneq (,$(findstring t,$(MAKEFLAGS)))
        +touch archive.a
        +ranlib -t archive.a
else
        ranlib archive.a
endif
The `+' prefix marks those command lines as "recursive" so that they will be executed despite use of the `-t' flag. See section Recursive Use of make.


GNU Make - Conditional Parts of Makefiles

'via Blog this'

Monday, November 26, 2012

DejaGnu, gcc, and runtest: Running Tests


4. Running Tests

There are two ways to execute a testsuite. The most common way is when there is existing support in the Makefile. This support consists of a check target. The other way is to execute the runtest program directly. To run runtest directly from the command line requires either all the correct options, or the Local Config File must be setup correctly.

4.1. Make check

To run tests from an existing collection, first use configure as usual to set up the build directory. Then try typing:
make check
      
If the check target exists, it usually saves you some trouble. For instance, it can set up any auxiliary programs or other files needed by the tests. The most common file the check builds is the site.exp. The site.exp file contains various variables that DejaGnu used to determine the configuration of the program being tested. This is mostly for supporting remote testing.
The check target is supported by GNU Automake. To have DejaGnu support added to your generated Makefile.in, just add the keyword dejagnu to the AUTOMAKE_OPTIONS variable in yourMakefile.am file.
Once you have run make check to build any auxiliary files, you can invoke the test driver runtest directly to repeat the tests. You will also have to execute runtest directly for test collections with no check target in the Makefile.

4.2. Runtest

runtest is the executable test driver for DejaGnu. You can specify two kinds of things on the runtest command line: command line options, and Tcl variables for the test scripts. The options are listed alphabetically below.
runtest returns an exit code of 1 if any test has an unexpected result; otherwise (if all tests pass or fail as expected) it returns 0 as the exit code.

4.2.1. Output States

runtest flags the outcome of each test as one of these cases. A POSIX Conforming Test Framework for a discussion of how POSIX specifies the meanings of these cases.


PASS
The most desirable outcome: the test succeeded, and was expected to succeed.
XPASS
A pleasant kind of failure: a test was expected to fail, but succeeded. This may indicate progress; inspect the test case to determine whether you should amend it to stop expecting failure.
FAIL
A test failed, although it was expected to succeed. This may indicate regress; inspect the test case and the failing software to locate the bug.
XFAIL
A test failed, but it was expected to fail. This result indicates no change in a known bug. If a test fails because the operating system where the test runs lacks some facility required by the test, the outcome isUNSUPPORTED instead.
UNRESOLVED
Output from a test requires manual inspection; the testsuite could not automatically determine the outcome. For example, your tests can report this outcome is when a test does not complete as expected.
UNTESTED
A test case is not yet complete, and in particular cannot yet produce a PASS or FAIL. You can also use this outcome in dummy ``tests'' that note explicitly the absence of a real test case for a particular property.
UNSUPPORTED
A test depends on a conditionally available feature that does not exist (in the configured testing environment). For example, you can use this outcome to report on a test case that does not work on a particular target because its operating system support does not include a required subroutine.
runtest may also display the following messages:


ERROR
Indicates a major problem (detected by the test case itself) in running the test. This is usually an unrecoverable error, such as a missing file or loss of communication to the target. (POSIX testsuites should not emit this message; use UNSUPPORTED, UNTESTED, or UNRESOLVED instead, as appropriate.)
WARNING
Indicates a possible problem in running the test. Usually warnings correspond to recoverable errors, or display an important message about the following tests.
NOTE
An informational message about the test case.

4.2.2. Invoking Runtest

This is the full set of command line options that runtest recognizes. Arguments may be abbreviated to the shortest unique string.


--all (-a)
Display all test output. By default, runtest shows only the output of tests that produce unexpected results; that is, tests with status FAIL (unexpected failure), XPASS (unexpected success), or ERROR (a severe error in the test case itself). Specify --all to see output for tests with status PASS (success, as expected) XFAIL (failure, as expected), or WARNING (minor error in the test case itself).
--build [string]
string is a full configuration ``triple'' name as used by configure. This is the type of machine DejaGnu and the tools to be tested are built on. For a normal cross this is the same as the host, but for a canadian cross, they are separate.
--host [string]
string is a full configuration ``triple'' name as used by configure. Use this option to override the default string recorded by your configuration's choice of host. This choice does not change how anything is actually configured unless --build is also specified; it affects only DejaGnu procedures that compare the host string with particular values. The procedures ishost, istarget, isnative, and setupxfail} are affected by --host. In this usage, host refers to the machine that the tests are to be run on, which may not be the same as the build machine. If --build is also specified, then --host refers to the machine that the tests wil, be run on, not the machine DejaGnu is run on.
--host_board [name]
The host board to use.
--target [string]
Use this option to override the default setting (running native tests). string is a full configuration ``triple'' name of the form cpu-vendor-os as used by configure. This option changes the configuration runtestuses for the default tool names, and other setup information.
--debug (-de)
Turns on the expect internal debugging output. Debugging output is displayed as part of the runtest output, and logged to a file called dbg.log. The extra debugging output does not appear on standard output, unless the verbose level is greater than 2 (for instance, to see debug output immediately, specify --debug-v -v}). The debugging output shows all attempts at matching the test output of the tool with the scripted patterns describing expected output. The output generated with --strace also goes into dbg.log.
--help (-he)
Prints out a short summary of the runtest options, then exits (even if you also specify other options).
--ignore [name(s)]
The names of specific tests to ignore.
--objdir [path]
Use path as the top directory containing any auxiliary compiled test code. This defaults to .. Use this option to locate pre-compiled test code. You can normally prepare any auxiliary files needed with make.
--outdir [path]
Write output logs in directory path. The default is .}, the directory where you start runtest. This option affects only the summary and the detailed log files tool.sum and tool.log. The DejaGnu debug logdbg.log always appears (when requested) in the local directory.
--reboot [name]
Reboot the target board when runtest initializes. Usually, when running tests on a separate target board, it is safer to reboot the target to be certain of its state. However, when developing test scripts, rebooting takes a lot of time.
--srcdir [path]
Use path as the top directory for test scripts to run. runtest looks in this directory for any subdirectory whose name begins with the toolname (specified with --tool). For instance, with --toolgdb},runtest uses tests in subdirectories gdb.* (with the usual shell-like filename expansion). If you do not use --srcdir, runtest looks for test directories under the current working directory.
--strace [number]
Turn on internal tracing for expect, to n levels deep. By adjusting the level, you can control the extent to which your output expands multi-level Tcl statements. This allows you to ignore some levels of case orif statements. Each procedure call or control structure counts as one ``level''. The output is recorded in the same file, dbg.log, used for output from --debug.
--connect [program]
Connect to a target testing environment as specified by type, if the target is not the computer running runtest. For example, use --connect to change the program used to connect to a ``bare board'' boot monitor. The choices for type in the DejaGnu 1.4 distribution are rlogin, telnet, rsh, tip, kermit, and mondfe. The default for this option depends on the configuration most convenient communication method available, but often other alternatives work as well; you may find it useful to try alternative connect methods if you suspect a communication problem with your testing target.
--baud [number]
Set the default baud rate to something other than 9600. (Some serial interface programs, like tip, use a separate initialization file instead of this value.)
--target_board [name(s)]
The list of target boards to run tests on.
--tool[name(s)]
Specifies which testsuite to run, and what initialization module to use. --tool is used only for these two purposes. It is not used to name the executable program to test. Executable tool names (and paths) are recorded in site.exp and you can override them by specifying Tcl variables on the command line. For example, including "--tool gcc" on the runtest command line runs tests from all test subdirectories whose names match gcc.*, and uses one of the initialization modules named config/*-gcc.exp. To specify the name of the compiler (perhaps as an alternative path to what runtest would use by default), use GCC=binname on the runtest command line.
--tool_exec [name]
The path to the tool executable to test.
--tool_opts [options]
A list of additional options to pass to the tool.
--verbose (-v)
Turns on more output. Repeating this option increases the amount of output displayed. Level one (-v) is simply test output. Level two (-v-v}) shows messages on options, configuration, and process control. Verbose messages appear in the detailed (*.log) log file, but not in the summary (*.sum) log file.
--version (-V)
Prints out the version numbers of DejaGnu, expect and Tcl, and exits without running any tests.
--D[0-1]
Start the internal Tcl debugger. The Tcl debugger supports breakpoints, single stepping, and other common debugging activities. See the document "Debugger for Tcl Applications" by Don Libes. (Distributed in PostScript form with expect as the file expect/tcl-debug.ps.. If you specify -D1, the expect shell stops at a breakpoint as soon as DejaGnu invokes it. If you specify -D0, DejaGnu starts as usual, but you can enter the debugger by sending an interrupt (e.g. by typing C-c).
testfile.exp[=arg(s)]
Specify the names of testsuites to run. By default, runtest runs all tests for the tool, but you can restrict it to particular testsuites by giving the names of the .exp expect scripts that control them. testsuite.exp may not include path information; use plain filenames.
testfile.exp="testfile1 ..."
Specify a subset of tests in a suite to run. For compiler or assembler tests, which often use a single .exp script covering many different source files, this option allows you to further restrict the tests by listing particular source files to compile. Some tools even support wildcards here. The wildcards supported depend upon the tool, but typically they are ?, *, and [chars].
tclvar=value
You can define Tcl variables for use by your test scripts in the same style used with make for environment variables. For example, runtest GDB=gdb.old defines a variable called GDB; when your scripts refer to $GDB in this run, they use the value gdb.old. The default Tcl variables used for most tools are defined in the main DejaGnu Makefile; their values are captured in the site.exp file.

4.2.3. Common Options

Typically, you don't need must to use any command-line options. --tool used is only required when there are more than one testsuite in the same directory. The default options are in the local site.exp file, created by "make site.exp".
For example, if the directory gdb/testsuite contains a collection of DejaGnu tests for GDB, you can run them like this:
eg$ cd gdb/testsuite
   eg$ runtest --tool gdb
 
Test output follows, ending with:
=== gdb Summary ===

  # of expected passes 508
  # of expected failures 103
  /usr/latest/bin/gdb version 4.14.4 -nx
 
You can use the option --srcdir to point to some other directory containing a collection of tests:
eg$ runtest--srcdir /devo/gdb/testsuite
 
By default, runtest prints only the names of the tests it runs, output from any tests that have unexpected results, and a summary showing how many tests passed and how many failed. To display output from all tests (whether or not they behave as expected), use the --all option. For more verbose output about processes being run, communication, and so on, use --verbose. To see even more output, use multiple --verboseoptions. for a more detailed explanation of each runtest option.
Test output goes into two files in your current directory: summary output in tool.sum, and detailed output in  tool.log. (tool refers to the collection of tests; for example, after a run with --tool gdb, look for output files gdb.sum and gdb.log.)

4.3. The files DejaGnu produces.

DejaGnu always writes two kinds of output files: summary logs and detailed logs. The contents of both of these are determined by your tests.
For troubleshooting, a third kind of output file is useful: use --debug to request an output file showing details of what Expect is doing internally.

4.3.1. Summary File

DejaGnu always produces a summary output file tool.sum. This summary shows the names of all test files run; for each test file, one line of output from each pass command (showing status PASS or XPASS) orfail command (status FAIL or XFAIL); trailing summary statistics that count passing and failing tests (expected and unexpected); and the full pathname and version number of the tool tested. (All possible outcomes, and all errors, are always reflected in the summary output file, regardless of whether or not you specify --all.)
If any of your tests use the procedures unresolved, unsupported, or runtested, the summary output also tabulates the corresponding outcomes.
For example, after runtest --tool binutils, look for a summary log in binutils.sum. Normally, DejaGnu writes this file in your current working directory; use the --outdir option to select a different directory.
Example 19. Here is a short sample summary log
Test Run By rob on Mon May 25 21:40:57 PDT 1992
   === gdb tests ===
 Running ./gdb.t00/echo.exp ...
 PASS:   Echo test
 Running ./gdb.all/help.exp ...
 PASS:   help add-symbol-file
 PASS:   help aliases
 PASS:   help breakpoint "bre" abbreviation
 FAIL:   help run "r" abbreviation
 Running ./gdb.t10/crossload.exp ...
 PASS:   m68k-elf (elf-big) explicit format; loaded
 XFAIL:  mips-ecoff (ecoff-bigmips) "ptype v_signed_char" signed C types
                === gdb Summary ===
 # of expected passes 5
 # of expected failures 1
 # of unexpected failures 1
 /usr/latest/bin/gdb version 4.6.5 -q
      

4.3.2. Log File

DejaGnu also saves a detailed log file tool.log, showing any output generated by tests as well as the summary output. For example, after runtest --tool binutils, look for a detailed log in binutils.log. Normally, DejaGnu writes this file in your current working directory; use the --outdir option to select a different directory.
Example 20. Here is a brief example showing a detailed log for G++ tests
Test Run By rob on Mon May 25 21:40:43 PDT 1992

                === g++ tests ===

 --- Running ./g++.other/t01-1.exp ---
        PASS:   operate delete

 --- Running ./g++.other/t01-2.exp ---
        FAIL:   i960 bug EOF
 p0000646.C: In function `int  warn_return_1 ()':
 p0000646.C:109: warning: control reaches end of non-void function
 p0000646.C: In function `int  warn_return_arg (int)':
 p0000646.C:117: warning: control reaches end of non-void function
 p0000646.C: In function `int  warn_return_sum (int, int)':
 p0000646.C:125: warning: control reaches end of non-void function
 p0000646.C: In function `struct foo warn_return_foo ()':
 p0000646.C:132: warning: control reaches end of non-void function

 --- Running ./g++.other/t01-4.exp ---
        FAIL:   abort
 900403_04.C:8: zero width for bit-field `foo'
 --- Running ./g++.other/t01-3.exp ---
        FAIL:   segment violation
 900519_12.C:9: parse error before `;'
 900519_12.C:12: Segmentation violation
 /usr/latest/bin/gcc: Internal compiler error: program cc1plus got fatal signal

                === g++ Summary ===

 # of expected passes 1
 # of expected failures 3
 /usr/latest/bin/g++ version cygnus-2.0.1
 

4.3.3. Debug Log File

With the --debug option, you can request a log file showing the output from Expect itself, running in debugging mode. This file (dbg.log, in the directory where you start runtest) shows each pattern Expectconsiders in analyzing test output.
This file reflects each send command, showing the string sent as input to the tool under test; and each Expect command, showing each pattern it compares with the tool output.
Example 21. The log messages begin with a message of the form
expect: does {tool output} (spawn_id n)
  match pattern {expected pattern}?

        
For every unsuccessful match, Expect issues a no after this message; if other patterns are specified for the same Expect command, they are reflected also, but without the first part of the message (expect... match pattern).
When Expect finds a match, the log for the successful match ends with yes, followed by a record of the Expect variables set to describe a successful match.
Example 22. Here is an excerpt from the debugging log for a GDB test:
send: sent {break gdbme.c:34\n} to spawn id 6
 expect: does {} (spawn_id 6) match pattern {Breakpoint.*at.* file
 gdbme.c, line 34.*\(gdb\) $}? no
 {.*\(gdb\) $}? no
 expect: does {} (spawn_id 0) match pattern {return} ? no
 {\(y or n\) }? no
 {buffer_full}? no
 {virtual}? no
 {memory}? no
 {exhausted}? no
 {Undefined}? no
 {command}? no
 break gdbme.c:34
 Breakpoint 8 at 0x23d8: file gdbme.c, line 34.
 (gdb) expect: does {break gdbme.c:34\r\nBreakpoint 8 at 0x23d8:
 file gdbme.c, line 34.\r\n(gdb) } (spawn_id 6) match pattern
 {Breakpoint.*at.* file gdbme.c, line 34.*\(gdb\) $}? yes
 expect: set expect_out(0,start) {18}
 expect: set expect_out(0,end) {71}
 expect: set expect_out(0,string) {Breakpoint 8 at 0x23d8: file
 gdbme.c, line 34.\r\n(gdb) }
 epect: set expect_out(spawn_id) {6}
 expect: set expect_out(buffer) {break gdbme.c:34\r\nBreakpoint 8
 at 0x23d8: file gdbme.c, line 34.\r\n(gdb) }
        PASS:   70      0       breakpoint line number in file
 
This example exhibits three properties of Expect and DejaGnu that might be surprising at first glance:

  • Empty output for the first attempted match. The first set of attempted matches shown ran against the output {} --- that is, no output. Expect begins attempting to match the patterns supplied immediately; often, the first pass is against incomplete output (or completely before all output, as in this case).
  • Interspersed tool output. The beginning of the log entry for the second attempted match may be hard to spot: this is because the prompt {(gdb) } appears on the same line, just before the expect: that marks the beginning of the log entry.
  • Fail-safe patterns. Many of the patterns tested are fail-safe patterns provided by GDB testing utilities, to reduce possible indeterminacy. It is useful to anticipate potential variations caused by extreme system conditions (GDB might issue the message virtual memory exhausted in rare circumstances), or by changes in the tested program (Undefined command is the likeliest outcome if the name of a tested command changes).
    The pattern {return} is a particularly interesting fail-safe to notice; it checks for an unexpected RET prompt. This may happen, for example, if the tested tool can filter output through a pager.
    These fail-safe patterns (like the debugging log itself) are primarily useful while developing test scripts. Use the error procedure to make the actions for fail-safe patterns produce messages starting withERROR on standard output, and in the detailed log file.


Running Tests:

'via Blog this'

Monday, November 12, 2012

Building GCC: configure option to pass CFLAGS into generated Makefiles? (the Monkey Speaks)



I am hoping I can use "configure --enable..." below to pass one of the CFLAGS mentioned here into the generated Makefiles that are used when I build gcc, so I can have a copy of gcc that contains the intermediate assembly source...  (Why? It's complicated).


I do not mind script-hacking Makefiles directly, which I have done before, but somehow it seems like it may the wrong way. (?) 





Sometimes, I think that GCC is the monolith, and I am a monkey, with some bones...





-save-temps=obj , -save-temps=cwd, & other optimizations from GCC 4.5 General Optimizer Improvements




--enable-cxx-flags=FLAGS


With this option, you can pass a string of -f (functionality) flags to the compiler to use when building libstdc++. This option can change the library ABI. FLAGS is a quoted string of options, like
--enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'
Note that the flags don't necessarily have to all be -f flags, as shown, but usually those are the ones that will make sense for experimentation and configure-time overriding.
The advantage of --enable-cxx-flags over setting CXXFLAGS in the 'make' environment is that, if files are automatically rebuilt, the same flags will be used when compiling those files as well, so that everything matches.


Fun with GCC: Configure

'via Blog this'

Why a gcc build creates so many temporary files [LinuxForums]

Quote Originally Posted by hazel View Post
I've just done the first deep update of my system. To my surprise and satisfaction, it recompiled specifically for my machine quite a few packages that had originally come with the stage 3 tarball, including gcc. I was also impressed by the messages that portage gave me, explaining exactly what tidying up operations would be necessary afterwards.

While gcc was compiling, I monitored the number of files the build was creating by using df -i periodically (I already knew it was a large number). The number of inodes consumed was about 55 thousand! That is grotesque! What kind of a process needs 55,000 files? I know that the compiler must create an object file for each source file but were there really 27,000 source files in this package? Just what is going on here?
gcc is a huge piece of software. It is not just a C compiler, it can do much more. It understands a number of languages, not just C, and is also a cross compiler. It can compile for a huge number of architectures.

The source package contains more than 10,000 .c files, and a total amount of +60,000 files, add to that the intermediate files and you can start realizing the magnitudes we are talking about.

I found it interesting...  Cheers, Connie

Code:
$ tar xf /var/portage/distfiles/gcc-4.3.3.tar.bz2 
$ find gcc-4.3.3/ -name \*.c|wc -l
11926
$ find gcc-4.3.3/ -name \*|wc -l
61659
Makefiles will be created when the configure script is run, and a lot of intermediate object files will be created as you say while compiling. Oh! and don't forget that gcc automatically bootstraps itself. That means that each time you emerge gcc, this happens:

  • first, gcc is compiled using whatever compiler you have on your system
  • second, gcc is re-compiled using the gcc version that you just compiled
  • third, gcc is recompiled again using the gcc produced on the second step, then both are compared (the third and the second) to see if they are 1:1 the same and ensure that there's no problem.


Now you can start wondering how the number of intermediate files is really huge.

And don't forget that in amd64 if you have multilib enabled two entire compilers are created for 32 and 64 bits, that means that gcc will be recompiled 6 times, and will double the total number of files once again.

Why does a build create so many temporary files?

'via Blog this'

Thursday, November 1, 2012

Don't worry (about gcc), be happy...

Randomly noticed these reassuring comments I see when grep'ing through the gcc source code for a compiler that we use daily:
...
../mpc-0.8.2/ltmain.sh:           # CHECK ME:  I think I busted this.  -Ossama
../mpc-0.8.2/ltmain.sh:     # CHECK ME:  I think I busted this.  -Ossama
...

I think this is *actually worse* than a FIXME.


What, me worry?  :-)

Connie "Gotta Love Open Source" O'Dell

'via Blog this'

Thursday, October 25, 2012

Compiler Architect & Technical Lead Engineer at Paneve in Boulder Area - Job | LinkedIn


Job Description

Panève is looking for a Compiler team manager/leader with strong technical and leadership skills.  Panève has developed a threaded architecture in conjunction with an innovative memory architecture to solve the big data problem in a very unique way.  We have been told that we have cracked the big data and parallel code.

Desired Skills & Experience

Responsible for parallel compilation, parallel runtime and other compilation tools.
Academic and/or professional experience in the design/porting/internals of GCC, LLVM, Clang, parallel computing is highly desirable.  


Company Description


Panève has developed our Direct-Cache Data-flow memory technology to offer a high performance Big Data platform, scalable enough to hold, process and manage the largest data sets and to support data solutions that cannot be done today. In-memory, scalable to petabytes, processing + storage at cache speeds.

Our proprietary Direct-Cache memory system allows us to access all memory, whether on or off chip, as if it were cache resulting in a 10,000/1 data access advantage. For Big Data, Panève has designed an innovative module called the ZettaTree. ZettaTree merges intense amounts of memory with intense amounts of compute power into one flexible, scalable, easy to manage processing+storage device.

For consumer electronics, Panève uses the same architectural design to deliver a processor called the RhinoCore™. RhinoCore delivers breakthrough performance and software programmability (think flexible).

Additional Information

Posted:
October 11, 2012
Type:
Full-time
Experience:
Mid-Senior level
Functions:
Engineering 
Industries:
Computer Hardware 
Job ID:
3937350

Search More Jobs


Compiler Architect & Technical Lead at Paneve in Boulder Area - Job | LinkedIn

'via Blog this'

GCC Optimize Options - Using the GNU Compiler Collection (GCC)


3.10 Options That Control Optimization

These options control various sorts of optimizations.
Without any optimization option, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you expect from the source code.
Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program.
The compiler performs optimization based on the knowledge it has of the program. Compiling multiple files at once to a single output file mode allows the compiler to use information gained from all of the files when compiling each of them.
Not all optimizations are controlled directly by a flag. Only optimizations that have a flag are listed in this section.
Most optimizations are only enabled if an -O level is set on the command line. Otherwise they are disabled, even if individual optimization flags are specified.
Depending on the target and how GCC was configured, a slightly different set of optimizations may be enabled at each -O level than those listed here. You can invoke GCC with -Q --help=optimizers to find out the exact set of optimizations that are enabled at each level. See Overall Options, for examples.
-O
-O1
Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.With -O, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time. -O turns on the following optimization flags:
-fauto-inc-dec 
          -fcompare-elim 
          -fcprop-registers 
          -fdce 
          -fdefer-pop 
          -fdelayed-branch 
          -fdse 
          -fguess-branch-probability 
          -fif-conversion2 
          -fif-conversion 
          -fipa-pure-const 
          -fipa-profile 
          -fipa-reference 
          -fmerge-constants
          -fsplit-wide-types 
          -ftree-bit-ccp 
          -ftree-builtin-call-dce 
          -ftree-ccp 
          -ftree-ch 
          -ftree-copyrename 
          -ftree-dce 
          -ftree-dominator-opts 
          -ftree-dse 
          -ftree-forwprop 
          -ftree-fre 
          -ftree-phiprop 
          -ftree-slsr 
          -ftree-sra 
          -ftree-pta 
          -ftree-ter 
          -funit-at-a-time
     
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. 
-O2
Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code.-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags:
-fthread-jumps 
          -falign-functions  -falign-jumps 
          -falign-loops  -falign-labels 
          -fcaller-saves 
          -fcrossjumping 
          -fcse-follow-jumps  -fcse-skip-blocks 
          -fdelete-null-pointer-checks 
          -fdevirtualize 
          -fexpensive-optimizations 
          -fgcse  -fgcse-lm  
          -fhoist-adjacent-loads 
          -finline-small-functions 
          -findirect-inlining 
          -fipa-sra 
          -foptimize-sibling-calls 
          -fpartial-inlining 
          -fpeephole2 
          -fregmove 
          -freorder-blocks  -freorder-functions 
          -frerun-cse-after-loop  
          -fsched-interblock  -fsched-spec 
          -fschedule-insns  -fschedule-insns2 
          -fstrict-aliasing -fstrict-overflow 
          -ftree-switch-conversion -ftree-tail-merge 
          -ftree-pre 
          -ftree-vrp
     
Please note the warning under -fgcse about invoking -O2 on programs that use computed gotos. 
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options. 
-O0
Reduce compilation time and make debugging produce the expected results. This is the default. 
-Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.-Os disables the following optimization flags:
-falign-functions  -falign-jumps  -falign-loops 
          -falign-labels  -freorder-blocks  -freorder-blocks-and-partition 
          -fprefetch-loop-arrays  -ftree-vect-loop-version
     
-Ofast
Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math and the Fortran-specific -fno-protect-parens and -fstack-arrays. 
-Og
Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.
Options of the form -fflag specify machine-independent flags. Most flags have both positive and negative forms; the negative form of -ffoo is -fno-foo. In the table below, only one of the forms is listed—the one you typically use. You can figure out the other form by either removing `no-' or adding it.
The following options control specific optimizations.
...
More at:
Optimize Options - Using the GNU Compiler Collection (GCC)

'via Blog this'