This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gold: Testsuite


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]