Unit tests of internal functions

[Nicolas Williams]

On Mon, Dec 28, 2009 at 06:01:54PM -0500, Ken Raeburn wrote:
> On Dec 28, 2009, at 15:11, ghudson at MIT.EDU wrote:
> > 1. Just export those symbols, as we do in a number of cases already.
> 
> Exporting more symbols increases library size and reduces performance,  
> though not a great deal in any individual case.  It also adds the  
> possibility of an application either calling the function directly, or  
> interposing its own version of the function, both of which I think it  
> would be good to prevent.  (And if we want to allow interposition, we  
> should discuss which functions can be replaced, and when we should  
> call the externally visible and replaceable versions of functions  
> versus internal, non-exposed ones, from other library routines.)

If you export as protected or direct bound symbols then library size and
rtld performance should not be affected, at least on Solaris (where
local symbols are retained for observability unless you strip the
object).

I prefer this approach.

> > 2. Make those symbols available through the accessor.  I would
> > personally find this annoying, but it's a valid option.  This only
> > really helps us in libkrb5, not for other libraries.  (We have
> > libk5crypto symbols available in the accessor, but it's kind of silly
> > since they currently have to be exported from libk5crypto to
> > accomplish that.)
> 
> We could make a crypto-library accessor as well.  The accessor is  
> awkward to use directly, but a helper file could be generated to  
> simplify things.  (E.g., by defining static function pointers or  
> functions or macros such that "foo()" in the test winds up actually  
> calling internal function foo via the accessor.)

The accessor does add to library size, and in a way that you can't
actually strip.

> > 3. During make check, build a second version of each shared library
> > with no restricted export list, and link test programs against that.
> 
> Or at least a much larger export list, including all the functions to  
> be tested.

Right.

> > 4. During make check, build static versions of each library and link
> > test programs against that.  Zhana raised the objection that shared
> > libraries should be tested as shared libraries, but I think that's
> > only important for system tests (like the ones we have in
> > tests/dejagnu), not unit tests.
> 
> Also relevant for performance testing, since PIC register use will  
> affect register allocation, etc.  It also affects the handling of  
> initialization/finalization code; system tests should catch most  
> problems, but we might want to add tests someday to look for problems  
> specifically in that code.
> 
> None of the options look particularly pretty, but in the interest of  
> testing something that most closely resembles the code to be  
> installed, I think I'd favor #2 or #3...

I favor #1.