This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Test optimizations for multiple architectures


On Thu, Nov 11, 2010 at 2:42 PM, Roland McGrath <roland@redhat.com> wrote:
>> --enable-test-multi-arch is intended for development build, not for production
>> build. My glibc development build environment is totally separate from the
>> production build environment. That is true for my gcc, binutils and gdb builds.
>
> People who have to maintain production builds need to run full test suites
> on the actual production code. ?Otherwise it's just not testing you can
> rely on. ?Doing more testing on your far-from-production development builds
> is of course better than not doing that testing. ?But it's not a substitute
> for more complete testing on the real builds.
>
>> You need to be very careful about circular dependency. The current runtime
>> selection doesn't require relocations. Anything more complex may require
>> relocations at run-time.
>
> I think you may have misunderstood what I proposed. ?The way ifunc works
> makes it essentially impossible to use anything in the selectors that
> requires other relocation, so we would never change it to be more complex.
> What I suggested involved no changes whatsoever in how the current ifunc
> selector code works. ?The new call would just be a way to preinitialize
> those bitmaps so the selector code never runs cpuid et al.
>

What you suggested is certainly different from mine.
I want a way to test all ifunc functions in one run. You
want to give user control which implementation the
ifunc selector should return. I think they are independent
of each other.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]