Modifying the error parser

Setting the compiler vendor in the libset.mk file

Each libset references its associated error parser via the VENDOR make macro in the libset.mk file. The toolset will execute scripts in the $OBJECTIME_HOME/codegen/compilers/$VENDOR/ directory to perform the conversion from the raw error stream to the Generic Error Stream (GES) format.

Reusing an existing error parser

If you are porting to a new libset, but using an existing compiler vendor, just set the VENDOR make macro in the libset.mk file to reference the existing vendor, and the error parsing port is done.

Creating a new error parser

If you are porting to a new vendor, you will need to pick a vendor acronym ($VENDOR) and create the directory $OBJECTIME_HOME/codegen/compilers/$VENDOR. You will need to create two files in this directory, otcompile.pl and otlink.pl, which you can copy from another vendor. These Perl files contain the following:

1. Inclusion of common code that performs all the error parsing functions.
2. Setting the errormode variable to indicate whether the file is parsing compiler errors or linker errors. Errormode is set to compilation by default.
3. Setting arrays of regular expressions and other information the common code will use to parse the raw error stream. There will be one set of variables per error expression handled. There will also be one set of variables for each expression that is ignored.
4. A call to the common code once array initializations are done to start parsing input.

   To complete the ports, delete the variables that deal specifically with the error expressions that are handled. You will then need to figure out what error expressions your compiler and linker generate and populate otcompile.pl or otlink.pl appropriately with new variables. There are a couple ways to efficiently determine what errors your compiler generates.

5. There is an error parser update available at http://www.objectime.com/support/restricted-dir/documentation.jspl, which contains a good number of common compilation errors. You can compile it and look at the compilation details file ($update_dir/compile.output) for the errors it generates. Add expressions one at a time and recompile until you have successfully captured all the errors.
6. Use programs that search the actual compiler or linker executable for strings. Then manually examine the output and intelligently determine which of the strings look like error statements.

   Each regular expression used is a Perl regular expression. If you are not familiar with Perl regular expressions it is suggested that you get a Perl book or find an equivalent reference online. Below is an explanation of how each variable can be used for error expression number X.

   The expression @oterr::start_error[X] indicates what pattern to look for to indicate that the current line being parsed is the beginning of the type of error expression X.

   @oterr::start_error[X] = '^.*:\d*: warning: .*';

   The expression @oterr::end_error[X] indicates which pattern to look for to indicate that the current line being parsed is the end of the type of error expression X. If the error is a single line error, it can be set to empty string. If the end of the error is too difficult to determine via a regular expression, it can be set to UNKNOWN. For the unknown case, it will consider every line part of the current error being parsed until it finds the beginning of another error, or a line it is supposed to ignore.

   @oterr::end_error[X] = '';

   @oterr::end_error[X] = 'UNKNOWN';

   @oterr::end_error[X] = '.*then contact your local service provider.*';

   Once the error has been isolated, the lines that compose it are concatenated into one string and the expression @oterr::regexps[X] is used to extract useful information from it. The parentheses in the regular expression pick out the filename, line number and error text respectively. Note that the Perl script is set up so that its wildcard characters can include newlines.

   @oterr::regexps[X] = '^(.*):(\d*): warning: (.*)';

   Each error type has to report to the toolset the severity of the error. Errors will cause the compilation to report a failure, while warnings will allow other steps, such as linking, to proceed.

   @oterr::severity[X] = 'warning';

   @oterr::severity[X] = 'error';

   Optionally, if a weird error turns up that does not have the filename argument first, then the line number, then the error text, you can include the expression @oterr::argorder[X] to change the order in which the program extracts the arguments from the parentheses in the @oterr::regexps[X] expression. By default this variable is set for all error types to be `FNE'.

   @oterr::argorder[X] = 'EFN';

   You can tell the error parser to ignore lines that the compiler or linker generate but are actually not anything you want to display in the error browser or map back to the toolset. There is one set of variables for each ignore statement that work very much like the variables for parsing a specific error type. Below is an explanation of how each variable can be used to ignore a specific type of expression Y.

   The @oterr::start_ignore[Y] statement indicates the beginning of a statement to ignore.

   @oterr::start_ignore[Y] = 'Copyright \(C\) .* Corp.*';

   The expression @oterr::end_ignore[Y] indicates which pattern to look for to indicate that the current line being parsed is the end of the type Y of expression that is being ignored. If the expression to be ignored is only one line, it can be set to empty string. Note that an `UNKNOWN' end of ignore statement is not supported.

   @oterr::end_ignore[Y] = '';

   @oterr::end_ignore[Y] = '\s*Version \d*.*';