numatop: %{optflags} fail the 32bit build
Dridi Boukelmoune
dridi.boukelmoune at gmail.com
Fri Sep 13 08:19:24 UTC 2013
On Thu, Sep 12, 2013 at 5:39 PM, Dave Jones <davej at redhat.com> wrote:
> On Wed, Sep 11, 2013 at 08:46:33AM +0200, Florian Weimer wrote:
>
> > This is the offending function:
> >
> > void
> > cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> > unsigned int *edx)
> > {
> > __asm volatile
> > ("cpuid\n\t"
> > : "=a" (*eax),
> > "=b" (*ebx),
> > "=c" (*ecx),
> > "=d" (*edx)
> > : "a" (*eax));
> > }
> >
> > The cryptic GCC error message (inconsistent operand constraints in
> > an ‘asm’) refers to the fact that in PIC mode (which is activated
> > by the hardening flags), %ebx is a reserved register.
> >
> > This version should work in 32 bit mode, and only in 32 bit mode:
> >
> > void
> > cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> > unsigned int *edx)
> > {
> > __asm volatile
> > ("push %%ebx\n\t"
> > "cpuid\n\t"
> > "mov %%ebx, (%1)\n\t"
> > "pop %%ebx"
> > : "=a" (*eax),
> > "=S" (ebx),
> > "=c" (*ecx),
> > "=d" (*edx)
> > : "0" (*eax));
> > }
> >
> > I have not actually tested this. There are other solutions
> > floating around, but they are clearly incorrect and produce wrong
> > code.
>
> A better fix would be to rip all this out, and use reads from
> /dev/cpu/*/cpuid, which is arch agnostic, and also takes care of cpu affinity problems.
>
> Dave
On my ubuntu machine at work, I have this:
$ ls /dev/cpu/
microcode
Also, wouldn't it be a problem on a chrooted environment ?
And during my tests I've noticed that numatop calls cpuid once for
each core on my laptop. It should discard the affinity problem,
shouldn't it ?
Tanks again for your help, it's been very interesting for me !
Dridi
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel
mailing list