Re: [gold patch rfa] print "error: " in front of error messages

[Chris Demetriou <cgd at google dot com>]

On Wed, Feb 4, 2009 at 22:17, Ian Lance Taylor <iant@google.com> wrote:
> My original intent was that anything that gold prints, which does not
> say "warning", is an error.  It's true that gold_info() doesn't say
> "warning", but that is only used for specific options where the output
> should be clear.  I think this behaviour is consistent with GNU ld,
> not that we have to be consistent.

Ahh, interesting.  I didn't know that was the intent.

FYI, depending on how gold is compiled there's more output: if i'm
reading the source correctly, if gold is compiled with -DDEBUG it
prints a greeting to stderr.

Other options, e.g. --stats and --trace, output directly to stderr
without going through gold_info.

Also, who's to say what output a plugin might generate.  (OK, there's
style guidance to be given there, and this is a hypothetical... but I
can easily imagine plugins having a flag which prints non-error
diagnostics.)


> Can you give an example of the kind of output you are getting that is
> hard to work with?

I was trying to do some (minimal) scraping of build logs, so as to
track errors encountered during nightly builds of a large code base
using the GCC lto branch.  The build helps a bit by marking what (it
thinks) is output from compiler vs. linker.

Anyway, the linker generates a lot of output, including --stats
output, link warnings, link errors, and linker assertions.  Also, as
mentioned, we're using the LTO plugin... with args that dump
information about compiler performance, too.

In theory, I could be looking for all messages that start with
'^/path/to/linker/in/gcc/subprogram/directory/ld: ' at the start of
output lines, but that doesn't catch assertions (apparently from the
plugin) which just start with '^ld: '.  OK, I could add that... and
then filter out all of the 'known' non-error messages... but that set
may change, and it's well-known.

Either way, without a consistent error marking, i've got an
arbitrary-length list of regexps to match or reject output.

As it is, between compiler errors (easy) and linker errors that we
know we care about, my list of regexps to look for is:

      $line =~ /[ :](error|undefined reference to|multiple definition
of)[ :]/ ||  # compiler and linker
      $line =~ /: missing expected TLS relocation$/ ||
            # extra bonus linker
      $line =~ /^error: / ||
                           # plugin perror IIRC
      $line =~ /^ld: .*Assertion `.*' failed.$/
                     # plugin assert failure IIRC

(There are obviously a bunch more linker errors possible, but I've not
seen any that cause enough of an impact on our builds that I've hunted
them down in the logs.)


Given your guidance above, the best solution given gold's philosophy
*would be* to match lines matching something like '^(/.*[-/]|)ld:',
then reject ones that show up due to warnings, the startup banner,
known stats messages, and known info messages.  the 'known' part there
is open-ended and bugs me a bit... and the list isn't short.  It would
be a bunch of additional expressions.

Looking for minor variations on 'error' is likely to be more
maintainable long-term, especially since plugin errors are likely to
have the string 'error' as well.  (It's still not perfect, because of
things like the 'Assertion .* failed' message from failed asserts.
Could add plugin APIs for diagnostic output and assertions, if they
aren't there already, but that might be overkill.)


Looking further at my patch and all instances of fprintf.stderr in
gold, I see I missed Errors::error_at_location and
Errors::undefined_symbol.  If tagging things with "error: " is OK with
you, I'd want to add it to those as well.


chris