Re: Gold: Testsuite

[Viktor Kutuzov <vkutuzov@accesssoftek.com>]

One day I will learn how to reply to All...

Thanks,
Viktor

----- Original Message ----- 
From: "Viktor Kutuzov" <vkutuzov@accesssoftek.com>
To: "Ian Lance Taylor" <iant@google.com>
Sent: Tuesday, September 01, 2009 6:18 PM
Subject: Re: Gold: Testsuite


Hi Ian,

I have been thinking along the same line.

However, I also think that cross-linker is a very important thing to support nicely.
And C/C++ is not the only codegenerator we link. If the same C/C++ code could be generated differently for different platforms, this
could lead to hard-to-catch issues in the unit tests itself.

Anyway, I'll send the unit test patch with the separate e-mail ina minute.

Best regards,
Viktor

----- Original Message ----- 
From: "Ian Lance Taylor" <iant@google.com>
To: "Viktor Kutuzov" <vkutuzov@accesssoftek.com>
Cc: <binutils@sourceware.org>
Sent: Monday, August 31, 2009 7:10 PM
Subject: Re: Gold: Testsuite


Viktor Kutuzov <vkutuzov@accesssoftek.com> writes:

> I'm looking at the configure.ac. The idea is to have a set of asm
> files and "correct" obj dumps to compare the result with (I'd prefer
> to keep all dependencies inside binutils as much as reasonable).

To be clear, I do not want to follow the pattern of comparing against
precise objdump results.  My experience with the gas testsuite, which
works that way, is that far too often unrelated changes to the tools
require the testsuite to change.  That makes these tests poor ways to
test functionality.  Developers wind up automatically adjusting the
tests to match the tool output, rather than using the test to actually
verify that the tool output is correct.

In my opinion, a test which can be run in a program is by far the best
approach.  That tests that the tool actually generates working output.
That is why basic_test.cc, and indeed much of the linker testsuite, is
written the way it is.  Of course, that approach only works for a native
linker.

For a cross-linker, testing the output with readelf (not objdump!) is
going to be the only reasonable approach.  But it's important to not try
to match the readelf output precisely, but to instead grep the readelf
output for the necessary output.  Ideally the input would be C/C++ code,
so that the same test can be reused for multiple targets.  Of course in
some cases the input must be assembler code.


> Is there a "standard" directory structure for the platform specific
> filees?  Should I create a new "arm" directory under the
> gold/testsuite and place everything there?

For cases where assembler input is required, that seems reasonable.

Ian