Re: RFC: Test optimizations for multiple architectures

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Nov 11, 2010 at 9:33 AM, Roland McGrath <roland@redhat.com> wrote:
> I'd be more inclined to provide some mechanism to mask the feature flags
> that are used to decide which function to chose, somewhat analogous to
> LD_HWCAP_MASK. ?For the implementations used with ifunc, an environment
> variable like that isn't necessarily what makes sense. ?There could be a
> special libc function that you call with a mask, either a mask of the
> hardware cpuid bits (gets hairy quickly), or, if it's purely a private
> function for internal use only, a mask of the internal form that
> init-arch.h uses. ?Then the tester could do multiple runs of all the tests,
> with different permutations of which bits are set.
>
> I'm not very sanguine about doing a special build of the library just for
> testing the multi-arch code.

Your suggestion means:

1. People have to know how to set up environment.
2. People have to make multiple runs of all the tests with different
permutations of which bits are set.

It is very easy to miss some permutations,  With my approach, I
can configure glibc with --enable-test-multi-arch and don't have
to do anything else.

> Conceivably it could make sense to make this a user-accessible feature too.
> I'm sure one day there will be some bug or performance workaround issue
> where someone wants to tweak the selection of functions at runtime. ?But
> there is not really any good interface for that, so we probably should not
> be eager to decide it. ?If we have a GLIBC_PRIVATE entry point that we use
> in our tests, then it will always be possible for someone sufficiently
> desperate to write a LD_PRELOAD kludge that calls it or suchlike.
>

--enable-test-multi-arch is disabled by default for a reason. It is mainly
for glibc developers.  I won't recommend OSVs to distribute glibc
configured with --enable-test-multi-arch.


-- 
H.J.