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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
