Bug#584748: ../sysdeps/x86_64/cacheinfo.c:255: handle_intel: Assertion `maxidx >= 2' on AMD cpu
severity 584748 important
clone 584748 -1
reassign -1 valgrind
retitle -1 valgrind: load i686 libraries while emulating an i586 CPU
thanks
On Mon, Jun 07, 2010 at 12:16:00PM +0200, Aurelien Jarno wrote:
> On Mon, Jun 07, 2010 at 08:47:23AM +0200, Aurelien Jarno wrote:
> > Aurelien Jarno a écrit :
> > > On Sun, Jun 06, 2010 at 10:27:12PM +0200, Gianluigi Tiesi wrote:
> > >> On 06/06/2010 14.55, Aurelien Jarno wrote:
> > >>> On Sun, Jun 06, 2010 at 02:17:29PM +0200, Gianluigi Tiesi wrote:
> > >>>> On 06/06/2010 13.21, Aurelien Jarno wrote:
> > >>>>>> Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/8 CPU cores)
> > >>>>> This part is not consistent. Are you running reportbug on a different
> > >>>>> machine?
> > >>>> yes
> > >>>>
> > >>>> the problem is on a old amd 800mhz box, but I use a different box
> > >>>> for submitting
> > >>>>
> > >>>> do you need some additional infos about the amd installation?
> > >>>>
> > >>> Yes, which libc6 packages are actually installed? I have fixed a bug
> > >>> that my cause the problem you are observing in version 2.11.1-2, so if
> > >>> you are running version 2.11.1-1, please try to upgrade.
> > >>>
> > >>> Also which kernel are you running?
> > >> libc is 2.11.1-2
> > >> kernel: Linux attila 2.6.32-5-686 #1 SMP Tue Jun 1 04:59:47 UTC 2010 i686 GNU/Linux
> > >>
> > >> I known the problem with libc6-i686 and intel i7 I've reported some info too :)
> > >
> > > It's not the problem with core i7, but a different one that has also
> > > been corrected. One that breaks reading model and family in some
> > > conditions.
> > >
> > >> this look different
> > >>
> > >
> > > Unfortunately I am not able to reproduce it. Tried on an Athlon and on
> > > Opteron CPU.
> > >
> >
> > For your information, I have been able to find a machine with a CPU
> > identical to yours, and I am now able to reproduce the issue. I'll debug
> > it later today.
> >
>
> Ok, here we go, it's a bit tricky.
>
> First of all, newer versions of the glibc tries to optimise the string
> function by using cache information, which are stored in cpuid level 2
> and later on an Intel CPU.
>
> Secondly, valgrind does not use the real CPU, but always emulates an
> Intel one, trying to match the characteristics of the host CPU,
> especially in term of instruction set. When the CPU has no SSE support
> it emulates an old Pentium CPU, which have a max a cpuid level of 1.
> This is what happens when the host CPU is an Athlon one.
>
> The Pentium CPU is an i586 CPU, which does not support the CMOV
> instruction, so the libc from the libc6 package is used. On the other
> hand, the Athlon CPU is an i686 CPU, which does support the CMOV
> instruction, so the libc from libc6-i686 is used.
>
> Everything works well as long as you don't use valgrind. When you use
> it, it loads all the libraries using the host CPUID, that is it loads
> the libc from libc6-i686. It latter emulates a Pentium CPU, which has
> a cpuid level of 1 only. The glibc code recognizes an Intel CPU (as
> valgrind emulates it), and given it is the i686 version of the libc, it
> assumes it is at minimum a Pentium Pro (which is the first i686 Intel
> CPU), which means it assumes that the cpuid level is at 2. This is
> where all the cache information is stored.
>
> The bug really seems to be on the valgrind side, which should not load
> an i686 library while emulating an i586 CPU. OTOH, if it is difficult
> to fix, we can maybe remove assumptions that are correct, but wrong when
> using valgrind.
>
I think the best is to fix this bug on both sides:
- Valgrind should present a cpuid consistent with the libraries it
loads
- There is no real reason in the GNU libc to trigger an assertion here,
0 can be returned for all the cache values here.
I am therefore cloning this bug and reassigning it to valgrind.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: