This is the mail archive of the
mailing list for the glibc project.
Re: Untested symbols
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sat, 20 Jul 2013 11:03:57 +0000
- Subject: Re: Untested symbols
- References: <Pine dot LNX dot 4 dot 64 dot 1307192154240 dot 14156 at digraph dot polyomino dot org dot uk> <20130720034539 dot GA5718 at domone>
On Sat, 20 Jul 2013, Ondrej Bilka wrote:
> > 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,
> Could you elaborate why? Among list is most of string, malloc, ctype functions
> with __ prefix. Creating files that duplicate test for normal symbol is
> just pointless.
If a symbol is part of the public interface, even if only for
libstdc++/libgcc, glibc tests should verify that the symbol works
properly. Such tests can of course #include another test with some extra
#defines, for example, if that's the most convenient way of testing a
symbol without duplication of test source code.
> Then there are math_finite symbols which are false positives.
No, they are not false positives. There is no test coverage for libm with
-ffinite-math-only. This allowed alpha to have a few releases where calls
to sqrt functions with -ffinite-math-only would not have worked.
Part of the point of adding such test coverage is to ensure such problems
- architecture-specific missing symbols that are meant to be part of the
public API - get detected without getting into releases.
> Also for _IO_* could be generaly make private.
Quite likely. Each reserved-namespace symbol in the list requires
separate investigation to determine whether it should have tests added, or
whether it should be made a compat symbol so newly linked programs cannot
use it - this is a choice for the person working on each individual symbol
to make and justify with an analysis included in their patch posting.
(In some cases, symbols made into compat symbols may also need a
GLIBC_PRIVATE version added, if there is good reason for other glibc
libraries to use a reserved-namespace version but not for code outside of
glibc to do so.)
> You need to clean that list more to be useful.
The way to clean the list of reserved-namespace symbols is to examine them
one-by-one manually and make them into compat symbols in glibc if they
don't need to be public interfaces - or, as applicable, to add testcases
(running the relevant parts of the libm tests with -ffinite-math-only, for
> > 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.
> More appropriate question is if this work is worth pursuing. For
> testing that interface exist you duplicate tests that are implicitly
> present in our testsuite by calling nonreserved symbols.
In general the tests are *not* present. As another example, consider how
fallocate64 was missing on 32-bit architectures in 2.10. It is still the
case that the glibc testsuite has no test coverage for fallocate64, so it
appears in this list of untested symbols.
Anyway, you can ignore the reserved-namespace symbols if you wish. That
reduces 1493 untested symbols (some in more than one library) to 916.
The bulk of those are symbols that could have genuine, meaningful tests of
their functionality added. It's extremely easy for people interested in
adding tests to find good functions to test in the list - we're a very
long way from the point where it's largely adding skeleton tests that
confirm that functions such as chown, delete_module, reboot or setuid
exist without being able to verify much more about those functions. (But
I still wouldn't recommend *removing* such functions from the list -
better to add the minimal tests to verify that calls compile and link, so
that no-one creates a glibc port that's accidentally missing them. Such a
minimal test of a root-only function is quick to add.)
Joseph S. Myers