Re: New ELF linker code added to GNU binutils

[Ian Lance Taylor <iant at google dot com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> I notice the testsuite isn't using DejaGnu.  No doubt this is convenient 
> for initial implementation, but DejaGnu tests support several features of 
> value in practice.

I used DejaGNU for years, and I really don't like it.  It is difficult
to work with and I think it encourages bad test writing.  I've written
the gold testsuite to focus on what I think matters, which is that you
can use the linker with the compiler to produce programs that do the
right thing when they are run.

Of course, a consequence is that the testsuite only works for native
development (apart from the unittests, of which there are currently
only two).  I recognize that this is a real deficiency for cross
development.  I would prefer to address that by using some sort of
script to run the program in the remote environment.  It would be fine
with me if that script uses DejaGNU.


> * Testing an installed toolchain through creating a site.exp file and 
> running runtest with appropriate options, rather than testing in the build 
> directory, so you can test the (relocatable) tools in exactly the 
> arrangements in which they will be distributed and used, or compare two 
> different tool versions on the same testsuite version.

It would be reasonably easy to modify the existing gold testsuite to
work this way.  We could simply change the uses of gcctestdir/ld and
-Bgcctestdir/ to use make variables instead.  Then you could pass the
appropriate make variables to run the testsuite.


Basically I really think DejaGNU has only one thing going for it,
which I admit is rather important: it has a lot of information about
running programs on different target boards.  I'm happy to use that
part of it, but I would prefer to stay away from it for the testsuite
in general.


Another significant drawback to the current gold testsuite, again
apart from the unittests, is that they only work for a complete
development system.  If you can't link a complete program, you can't
test gold.  I haven't really thought of a good approach for testing
the linker when you can't link a complete program, one which doesn't
fall into the trap of requiring you to update the test every time the
linker changes.

That is, I think a linker testsuite should test functionality.  It
shouldn't test that the output is unchanged from previous versions.  I
think that is a flaw in the GNU ld testsuite.  My best ideas along
these lines so far are to link very simple standalone test cases and
examine the output using readelf and objdump.  But really those are
insufficient for the purpose, and it would probably be necessary to
write some special purpose tools--e.g., a program which could open an
ELF file and use the symbol table to locate the address of a variable
and read the bytes at that address.


> The --version output is a bit strange:
>
> GNU gold (GNU binutils (GNU Binutils) 2.18.50.20080325) version 1.4
>
> (note the "GNU binutils (GNU Binutils)").  BFD_VERSION_STRING includes 
> both the package version ("(GNU Binutils)" by default, possibly overridden 
> by --with-pkgversion) and a version number - it's not expected for 
> binutils components to have their own independent version numbers such as 
> "1.4".  The word "version" isn't part of the standard --version output.

Yikes.  This was better when I wrote it--something must have changed
since the binutils snapshot I was using for development.  I'll clean
it up.


> The --help output doesn't include the bug-reporting URL (REPORT_BUGS_TO in 
> bfdver.h).

Thanks, I'll fix this too.

Ian