public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Possible bug in sysdeps/x86_64/cacheinfo.c
@ 2014-11-10 17:51 Paul Pluzhnikov
  2014-11-10 19:23 ` H.J. Lu
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Pluzhnikov @ 2014-11-10 17:51 UTC (permalink / raw)
  To: GLIBC Devel; +Cc: Ulrich Drepper

Greetings,

In sysdeps/x86_64/cacheinfo.c intel_check_word(), we have this code:

commit 2a1156010784332cbe4bf033ccedb19f52e56a75
Author: Ulrich Drepper <drepper@gmail.com>
Date:   Sun Mar 20 08:14:30 2011 -0400

    Implement x86 cpuid handling of leaf4 for cache information.

...

  asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1"
		: "=a" (eax), "=r" (ebx), "=c" (ecx), "=d" (edx)
		: "0" (4), "2" (round));

AFAICT, this clobbers the high 32 bits of %rbx, which causes a crash
if the caller had a live %rbx and non-0 high bits in it.

(I am not sure why this isn't causing a problem with current glibc
builds; possibly %rbx is not live?)

-- 
Paul Pluzhnikov

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Possible bug in sysdeps/x86_64/cacheinfo.c
  2014-11-10 17:51 Possible bug in sysdeps/x86_64/cacheinfo.c Paul Pluzhnikov
@ 2014-11-10 19:23 ` H.J. Lu
  2014-11-10 19:38   ` Paul Pluzhnikov
  0 siblings, 1 reply; 3+ messages in thread
From: H.J. Lu @ 2014-11-10 19:23 UTC (permalink / raw)
  To: Paul Pluzhnikov; +Cc: GLIBC Devel, Ulrich Drepper

On Mon, Nov 10, 2014 at 9:50 AM, Paul Pluzhnikov <ppluzhnikov@gmail.com> wrote:
> Greetings,
>
> In sysdeps/x86_64/cacheinfo.c intel_check_word(), we have this code:
>
> commit 2a1156010784332cbe4bf033ccedb19f52e56a75
> Author: Ulrich Drepper <drepper@gmail.com>
> Date:   Sun Mar 20 08:14:30 2011 -0400
>
>     Implement x86 cpuid handling of leaf4 for cache information.
>
> ...
>
>   asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1"
>                 : "=a" (eax), "=r" (ebx), "=c" (ecx), "=d" (edx)
>                 : "0" (4), "2" (round));
>
> AFAICT, this clobbers the high 32 bits of %rbx, which causes a crash
> if the caller had a live %rbx and non-0 high bits in it.
>
> (I am not sure why this isn't causing a problem with current glibc
> builds; possibly %rbx is not live?)
>

It was

https://sourceware.org/bugzilla/show_bug.cgi?id=17259

and fixed by

commit b4acef1ffe2e1ba6c608f31c1954a8100d3eabb0
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Aug 12 17:02:51 2014 -0700

    Replace cpuid asm statement with __cpuid_count

    The compiler doesn't know that the cpuid asm statement in intel_check_word
    will trash RBX.  We are lucky that it doesn't cause any problems since
    RBX is also used by compiler for other purposes so that RBX is saved and
    restored.  This patch replaces it with __cpuid_count.

      [BZ #17259]
      * sysdeps/x86_64/cacheinfo.c (intel_check_word): Replace cpuid
      asm statement with __cpuid_count.



-- 
H.J.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Possible bug in sysdeps/x86_64/cacheinfo.c
  2014-11-10 19:23 ` H.J. Lu
@ 2014-11-10 19:38   ` Paul Pluzhnikov
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Pluzhnikov @ 2014-11-10 19:38 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GLIBC Devel, Ulrich Drepper

On Mon, Nov 10, 2014 at 11:23 AM, H.J. Lu <hjl.tools@gmail.com> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=17259
> and fixed by
>
> commit b4acef1ffe2e1ba6c608f31c1954a8100d3eabb0
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date:   Tue Aug 12 17:02:51 2014 -0700
>
>     Replace cpuid asm statement with __cpuid_count

Thanks.

I did 'git pull' before sending my message, and did not see that commit
there. I do see it after 'git pull --all', and I do see it now.


-- 
Paul Pluzhnikov

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-11-10 19:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-10 17:51 Possible bug in sysdeps/x86_64/cacheinfo.c Paul Pluzhnikov
2014-11-10 19:23 ` H.J. Lu
2014-11-10 19:38   ` Paul Pluzhnikov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).