Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 32429 - glibc contain pentium specific code.
Summary: glibc contain pentium specific code.
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High minor (vote)
Assignee: Gentoo Toolchain Maintainers
URL: http://sources.redhat.com/bugzilla/sh...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-31 14:48 UTC by Tavis Ormandy (RETIRED)
Modified: 2005-12-23 07:52 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
rdtsc won't compile on i486 (coreutils-shred-rdtsc.diff,689 bytes, patch)
2004-02-27 13:45 UTC, Tavis Ormandy (RETIRED)
Details | Diff
libmemusage will sigill on i486 (glibc-memusage-rdtsc.diff,714 bytes, patch)
2004-02-27 13:45 UTC, Tavis Ormandy (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2003-10-31 14:48:36 UTC
couple of minor issues, glibc contains the following macro as part of libmemusage (the cool memory allocation profiler utility):

#define GETTIME(low,high) asm ("rdtsc" : "=a" (low), "=d" (high))

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/i386/memusage.h?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=glibc

rdtsc (ReaD Time Stamp Counter) is an instruction introduced with the pentium, and will SIGILL on any earlier chips (check URL). coreutils has a similar problem, /bin/shred uses this cpp logic to enable this pentium specific inline asm (more rdtsc):

        (...)
        static void
        isaac_seed_machdep (struct isaac_state *s)
        (...)
        # if __i386__                                                                                 
                word32 t[2];
                __asm__ __volatile__ ("rdtsc" : "=a" (t[0]), "=d"
                (t[1]));
        # endif                                                                                       
        (...)

It would be nice if gcc defined  __i486__, __i586__, etc if the target supports those extensions, then just s/1386/i586/ would do the trick, but no such luck :(
An ANSI C replacement is provided for unsupported architectures...some configure check should do the trick.

i486 is an supported architecture, should these be fixed...?
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2003-11-01 15:02:05 UTC
Sad thing is that i386 cannot even support c++ anymore, as libstdc++ need
i486+ instructions.
Comment 2 Seemant Kulleen (RETIRED) gentoo-dev 2004-02-21 16:22:16 UTC
so what shall we do about this, gentlemen?
Comment 3 David M. Andersen 2004-02-22 19:41:18 UTC
I guess you could clobber it with the generic one:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/sysdeps/generic/memusage.h?rev=1.2&content-type=text/plain&cvsroot=glibc

About macros... :-)

root@laureate:~# gcc -march=i486 -E -dD - < /dev/null
...
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i486__ 1
#define __i486 1
#define __i486__ 1
...

root@laureate:~# gcc -march=i586 -E -dD - < /dev/null
...
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i586__ 1
#define __tune_pentium__ 1
#define __i586 1
#define __i586__ 1
#define __pentium 1
#define __pentium__ 1
...
Comment 4 Tavis Ormandy (RETIRED) gentoo-dev 2004-02-23 15:33:32 UTC
Thanks for the link David, libmemusage isnt a speed critical, heavily used utility..i dont see a problem with using the pure c version instead of the inline asm? i suppose the same can be said for shred.

but the problem isnt with -march=i586/i486..its that pentium3/pentium4/i686 dont define __i586__! (I'm sure earlier gcc's did, but apparently that changed).

I would be very surprised if this code compiled on a 486, wouldnt the assembler say unrecognised instruction?
Comment 5 David M. Andersen 2004-02-23 19:11:50 UTC
Not sure how you'd do it.  If the GCC people add another architecture, this stuff would change anyway.  The assembler appears to generate all i386 instructions regardless of architecture chosen (which makes sense because run-time checks could disable the unsupported code I guess).

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/config/i386/i386.h?rev=1.368.2.2&content-type=text/plain&cvsroot=gcc

===== i386 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i386__ 1

===== i486 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i486__ 1
#define __i486 1
#define __i486__ 1

===== i586, pentium =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i586__ 1
#define __tune_pentium__ 1
#define __i586 1
#define __i586__ 1
#define __pentium 1
#define __pentium__ 1

===== pentium-mmx =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i586__ 1
#define __tune_pentium__ 1
#define __tune_pentium_mmx__ 1
#define __MMX__ 1
#define __i586 1
#define __i586__ 1
#define __pentium 1
#define __pentium__ 1
#define __pentium_mmx__ 1

===== i686, pentiumpro =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i686__ 1
#define __tune_pentiumpro__ 1
#define __i686 1
#define __i686__ 1
#define __pentiumpro 1
#define __pentiumpro__ 1

===== pentium2 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i686__ 1
#define __tune_pentiumpro__ 1
#define __tune_pentium2__ 1
#define __MMX__ 1
#define __i686 1
#define __i686__ 1
#define __pentiumpro 1
#define __pentiumpro__ 1

===== pentium3 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i686__ 1
#define __tune_pentiumpro__ 1
#define __tune_pentium3__ 1
#define __tune_pentium2__ 1
#define __MMX__ 1
#define __SSE__ 1
#define __i686 1
#define __i686__ 1
#define __pentiumpro 1
#define __pentiumpro__ 1

===== pentium4 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_pentium4__ 1
#define __MMX__ 1
#define __SSE__ 1
#define __SSE2__ 1
#define __pentium4 1
#define __pentium4__ 1

===== k6 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_k6__ 1
#define __MMX__ 1
#define __k6 1
#define __k6__ 1

===== k6-2 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_k6__ 1
#define __tune_k6_2__ 1
#define __MMX__ 1
#define __3dNOW__ 1
#define __k6 1
#define __k6__ 1
#define __k6_2__ 1

===== k6-3 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_k6__ 1
#define __tune_k6_3__ 1
#define __MMX__ 1
#define __3dNOW__ 1
#define __k6 1
#define __k6__ 1
#define __k6_3__ 1

===== athlon =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_athlon__ 1
#define __MMX__ 1
#define __3dNOW__ 1
#define __3dNOW_A__ 1
#define __athlon 1
#define __athlon__ 1

===== athlon-tbird =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_athlon__ 1
#define __MMX__ 1
#define __3dNOW__ 1
#define __3dNOW_A__ 1
#define __athlon 1
#define __athlon__ 1

===== athlon-xp, athlon-4, athlon-mp =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_athlon__ 1
#define __tune_athlon_sse__ 1
#define __MMX__ 1
#define __3dNOW__ 1
#define __3dNOW_A__ 1
#define __SSE__ 1
#define __athlon 1
#define __athlon__ 1
#define __athlon_sse__ 1

===== winchip-c6 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i486__ 1
#define __MMX__ 1
#define __i486 1
#define __i486__ 1

===== winchip2, c3 =====
#define __i386 1
#define __i386__ 1
#define i386 1
#define __tune_i486__ 1
#define __MMX__ 1
#define __3dNOW__ 1
#define __i486 1
#define __i486__ 1
Comment 6 Tavis Ormandy (RETIRED) gentoo-dev 2004-02-27 13:45:03 UTC
Created attachment 26485 [details, diff]
rdtsc won't compile on i486
Comment 7 Tavis Ormandy (RETIRED) gentoo-dev 2004-02-27 13:45:34 UTC
Created attachment 26486 [details, diff]
libmemusage will sigill on i486
Comment 8 Tavis Ormandy (RETIRED) gentoo-dev 2004-02-27 13:46:13 UTC
how about these? i486 is the only supported platform affected by this.
Comment 9 SpanKY gentoo-dev 2004-05-02 12:27:22 UTC
umm what version of glibc is affected ?
Comment 10 Tavis Ormandy (RETIRED) gentoo-dev 2004-05-02 14:10:24 UTC
Spanky: All releases for at least the last 3 years, inluding current cvs (see cvsweb link above)
Comment 11 SpanKY gentoo-dev 2004-05-03 05:13:27 UTC
ok, so i guess my point was that i dont understand why the bug is here and not sent to the glibc maintainers ;)
Comment 12 SpanKY gentoo-dev 2004-12-21 20:29:15 UTC
coreutils-5.2.1-r3 contains this patch
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2005-10-25 15:16:44 UTC
Uhm, what's the status here?
Comment 14 SpanKY gentoo-dev 2005-10-26 17:42:01 UTC
that's not how glibc fixes things

i386/ is only for code that will work on i386+

the i386/i686/memusage.h file is the exact same as i386/memusage.h which implies
this is prob a mistake

if we copy i386/i686/memusage.h to i386/i586/memusage.h and i386/i786/memusage.h
and then delete i386/memusage.h, i think that should be fine yeah ?
Comment 15 Mark Loeser (RETIRED) gentoo-dev 2005-12-15 00:08:41 UTC
So, have we fixed this?  Has someone brought it to upstream's attention?
Comment 16 SpanKY gentoo-dev 2005-12-15 06:24:58 UTC
*cough* read the URL field *cough*
Comment 17 Mark Loeser (RETIRED) gentoo-dev 2005-12-15 11:56:47 UTC
Halcy0n--  :)
Comment 18 SpanKY gentoo-dev 2005-12-23 07:52:04 UTC
fixed upstream, will be in next patchset