Untested symbols

["Joseph S. Myers" <joseph at codesourcery dot com>]

Following up on a recent discussion, attached are:

* A list of symbols exported by glibc's shared libraries (excluding 
GLIBC_PRIVATE symbols and compat symbols), on x86_64, that do not appear 
to be tested by any glibc testcase.

* The script that generated that list.

* The modified version of abilist.awk used by that script to determine 
symbols that should be tested.

The list generation is based on heuristics - look for <test>.out files in 
the build tree (where you must first have run the testsuite) and then look 
at dynamic symbols in the corresponding <test> file and presume they are 
covered by the testsuite.  As such, the list may not be perfect (it might 
include symbols that are tested but e.g. only by a shared library or other 
file whose name doesn't correspond to a .out file, or miss symbols that 
appear as dynamic symbols in a test but aren't adequately tested).

The list include reserved-namespace symbols.  This is deliberate.  For 
each such symbol, if there is a good reason for it to be in the public ABI 
(for example, for namespace-clean use in libstdc++ or libgcc, or because 
it is used by a public macro in an installed header), then it should be 
tested (if it's used via a macro, that macro should be tested as the 
interface actually exposed to users).  If there is no such good reason, 
the symbol should be made into a compat symbol (and added to 
GLIBC_PRIVATE, if needed by other glibc libraries).  (If the non-reserved 
version of a function is used by libstdc++ although the reserved version 
*should* be used there, that's probably sufficient reason to keep the 
reserved version in the public interface.)  A few cases may be tricky to 
test if e.g. the use is in macros that are still present in current glibc, 
but only for certain compiler versions.

I hope GNU/Linux distributors have tools that can answer questions of the 
form "what binaries in the whole distribution are using this dynamic 
symbol", as that would certainly be helpful in establishing whether some 
reserved-namespace symbol is actually being used (as a starting point for 
deciding whether it *should* be being used).

Some symbols are in fact tested but only in a way that ends up using a 
macro or inline function or GCC built-in function that hides the function 
exported from the shared library.  (For example, atof.)  In such cases, 
there should also be a test that makes sure to disable the inline / macro 
/ built-in function, so that the public interface to the shared library 
gets properly tested.

Some functions may only be tested for static links - but if it's in the 
shared library, the shared library version should be tested as well.

As noted in <http://sourceware.org/ml/libc-alpha/2013-07/msg00380.html>, 
if a function can't (usefully, or safely) be called from the testsuite it 
should still be verified that calls compile and link without warnings, 
e.g.

volatile int run_test = 0;

int
do_test (void)
{
  /* This interface needs root access to run, so we only test that
     calls to it compile and link.  */
  if (run_test)
    call_the_interface (arguments);
  return 0;
}

Certainly adding tests of all these functions (which should generally try 
to test that the main functionality of the interface works as specified, 
rather than just that the function exists) will be a lot of work, but it 
can be done a little bit at a time (and in many cases, making a function 
into a compat symbol may be the right approach).  I fully expect various 
bugs, both generic and architecture-specific, will be found in the 
process.

-- 
Joseph S. Myers
joseph@codesourcery.com

Attachment: untested-syms
Description: Text document

Attachment: list-untested-symbols
Description: Text document

Attachment: abilist-mod.awk
Description: Text document