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...?
Sad thing is that i386 cannot even support c++ anymore, as libstdc++ need i486+ instructions.
so what shall we do about this, gentlemen?
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 ...
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?
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
Created attachment 26485 [details, diff] rdtsc won't compile on i486
Created attachment 26486 [details, diff] libmemusage will sigill on i486
how about these? i486 is the only supported platform affected by this.
umm what version of glibc is affected ?
Spanky: All releases for at least the last 3 years, inluding current cvs (see cvsweb link above)
ok, so i guess my point was that i dont understand why the bug is here and not sent to the glibc maintainers ;)
coreutils-5.2.1-r3 contains this patch
Uhm, what's the status here?
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 ?
So, have we fixed this? Has someone brought it to upstream's attention?
*cough* read the URL field *cough*
Halcy0n-- :)
fixed upstream, will be in next patchset