|
From: Gustavo M. <gmo...@gm...> - 2008-08-28 23:06:38
|
I'm using valgrind-3.2.3 compiled with uClibc-0.9.29 (builroot), running in a PC-104 target (i486), but valgrind return unsupported CPU.... why!!!!!!!!???? [root@gcm ~]# valgrind valgrind: fatal error: unsupported CPU. Supported CPUs are: * x86 (practically any; Pentium-I or above), AMD Athlon or above) * AMD Athlon64/Opteron * PowerPC (most; ppc405 and above) [root@gcm ~]# cat /proc/cpuinfo processor : 0 vendor_id : unknown cpu family : 4 model : 0 model name : 486 stepping : unknown fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : -1 wp : yes flags : bogomips : 51.32 clflush size : 32 [root@gcm ~]# uname -a Linux gcm 2.6.24 #1 Wed Aug 27 11:17:54 ART 2008 i486 unknown The relevant kernel .config are: CONFIG_X86_32=y CONFIG_X86_PC=y CONFIG_M486=y |
|
From: tom f. <tf...@al...> - 2008-09-01 14:59:50
|
"Gustavo Moreira" <gmo...@gm...> writes: > I'm using valgrind-3.2.3 compiled with uClibc-0.9.29 (builroot), > running in a PC-104 target (i486), but valgrind return unsupported > CPU.... [snip] > [root@gcm ~]# cat /proc/cpuinfo > processor : 0 > vendor_id : unknown [snip] It sounds like the kernel doesn't even know what kind of CPU this is. Does the processor not provide the `cpuid' instruction? You might think about adding a `--no-really-its-x86-trust-me' command line option [1] which forces that instruction set (assuming the CPU implements a full or mostly-full x86 instruction set). (Disclaimer: I'm no dev; I have no clue if cpuid is used under the hood, I've no idea if such a `force iset' option already exists, and I certainly can't speak for whether or not such a patch would be accepted into VG.) -tom [1] Don't actually call it that. |
|
From: Tom H. <to...@co...> - 2008-09-01 16:10:26
|
tom fogal wrote: > "Gustavo Moreira" <gmo...@gm...> writes: >> I'm using valgrind-3.2.3 compiled with uClibc-0.9.29 (builroot), >> running in a PC-104 target (i486), but valgrind return unsupported >> CPU.... > [snip] >> [root@gcm ~]# cat /proc/cpuinfo >> processor : 0 >> vendor_id : unknown > [snip] > > It sounds like the kernel doesn't even know what kind of CPU this is. > Does the processor not provide the `cpuid' instruction? No, a 486 has a limited form of cpuid that doesn't provide as much information, so that output is normal. > You might think about adding a `--no-really-its-x86-trust-me' command > line option [1] which forces that instruction set (assuming the CPU > implements a full or mostly-full x86 instruction set). We know it's an x86. We also know that we don't support it because it's only a 486. The valgrind output originally quoted clearly explained the problem by saying that only Pentium and later processors are supported. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
>>> I'm using valgrind-3.2.3 compiled with uClibc-0.9.29 (builroot), >>> running in a PC-104 target (i486), but valgrind return unsupported >>> CPU.... > We know it's an x86. We also know that we don't support it because it's > only a 486. The valgrind output originally quoted clearly explained the > problem by saying that only Pentium and later processors are supported. The original poster seeks the specific reasons why a 486 isn't good enough. Which features of a Pentium-I are essential to valgrind? How sensitive are the requirements? Could a 486 work if the subject programs avoided using some instructions? Pentium-I has no SSE (only x87) , also P54C has no MMX; so valgrind's requirements must be very specific. Perhaps the original poster would be willing to modify valgrind enough to make it work on only a 486. A pointer to the specific documentation or source file which lists and explains the specific requirements would be appreciated, even to remind veteran developers. [Hint to original poster: modify the source of valgrind to bypass the test for minimum CPU requirements, then see how valgrind fails.] -- |
|
From: Julian S. <js...@ac...> - 2008-09-01 18:48:09
|
> The original poster seeks the specific reasons why a 486 isn't good enough. > Which features of a Pentium-I are essential to valgrind? None. 486 isn't supported only because it's yet another cpu variant which would have to be special-cased in code generation (eg, it doesn't support cmov) and other aspects (cpuid?), and then verified for each release. More code and variants always equates with more support effort in the end, and AFAIR this is the first time in 5+ years that we've been asked for 486 support. And to tell the truth, I never expected anyone to run it on such a lowly machine. By the time this project started, Pentium-I or equivalent (AMD K6s) were pretty much everywhere. J |
|
From: Gustavo M. <gmo...@gm...> - 2008-09-01 19:11:45
|
Ok, but PC-104 are usually i486 and is the most commonly used in industrial embedded systems, would be good to support it. GCM On Mon, Sep 1, 2008 at 15:38, Julian Seward <js...@ac...> wrote: > >> The original poster seeks the specific reasons why a 486 isn't good enough. >> Which features of a Pentium-I are essential to valgrind? > > None. 486 isn't supported only because it's yet another cpu variant > which would have to be special-cased in code generation (eg, it doesn't > support cmov) and other aspects (cpuid?), and then verified for each > release. More code and variants always equates with more support > effort in the end, and AFAIR this is the first time in 5+ years that > we've been asked for 486 support. > > And to tell the truth, I never expected anyone to run it on such > a lowly machine. By the time this project started, Pentium-I or > equivalent (AMD K6s) were pretty much everywhere. > > J > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |