|
From: Bart V. A. <bar...@gm...> - 2008-12-22 12:23:15
|
Hello Julian, A source code comment in m_machine.c says the following: /* ppc32 doesn't seem to have a sane way to find out what insn sets the CPU supports. So we have to arse around with SIGILLs. Yuck. */ I don't know everything about the PowerPC architecture, but by looking around in the Linux kernel sources I found out that the Linux kernel determines the PowerPC CPU type from the value in the PowerPC PVR register. A partial list of PVR values can be found here: http://www.freescale.com/files/archives/doc/support_info/PPCPVR.pdf?fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation Has it already been considered before to use the value of the PVR register for PPC instruction set detection in Valgrind ? Bart. |
|
From: Julian S. <js...@ac...> - 2008-12-22 13:48:40
|
> Has it already been considered before to use the value of the PVR > register for PPC instruction set detection in Valgrind ? No. I didn't know of its existence. Is the instruction usable from user space? In fact the SIGILL scheme works pretty well most of the time, afaics, and means we don't have to drag around a big table listing all known PowerPC/POWER CPUs. Is there a specific difficulty with the SIGILL scheme? J |
|
From: Bart V. A. <bar...@gm...> - 2008-12-22 13:58:52
|
On Mon, Dec 22, 2008 at 2:34 PM, Julian Seward <js...@ac...> wrote: > >> Has it already been considered before to use the value of the PVR >> register for PPC instruction set detection in Valgrind ? > > No. I didn't know of its existence. Is the instruction usable from > user space? > > In fact the SIGILL scheme works pretty well most of the time, afaics, > and means we don't have to drag around a big table listing all known > PowerPC/POWER CPUs. Is there a specific difficulty with the SIGILL > scheme? I'm not sure the PVR register is directly accessible from user space, but recent kernels make this information available through /proc/cpuinfo: $ cat /proc/cpuinfo ... processor : 3 cpu : Cell Broadband Engine, altivec supported clock : 3200.000000MHz revision : 5.1 (pvr 0070 0501) ... The reason I was asking about the PVR register is because apparently some PowerPC CPU's are not yet supported by Valgrind -- see e.g. http://bugs.kde.org/show_bug.cgi?id=176926. Bart. |
|
From: Julian S. <js...@ac...> - 2008-12-22 14:33:33
|
> The reason I was asking about the PVR register is because apparently > some PowerPC CPU's are not yet supported by Valgrind -- see e.g. > http://bugs.kde.org/show_bug.cgi?id=176926. It's a signal handling problem. I added a comment to http://bugs.kde.org/show_bug.cgi?id=176926. J |
|
From: Bart V. A. <bar...@gm...> - 2008-12-22 14:50:27
|
On Mon, Dec 22, 2008 at 3:19 PM, Julian Seward <js...@ac...> wrote: > >> The reason I was asking about the PVR register is because apparently >> some PowerPC CPU's are not yet supported by Valgrind -- see e.g. >> http://bugs.kde.org/show_bug.cgi?id=176926. > > It's a signal handling problem. I added a comment to > http://bugs.kde.org/show_bug.cgi?id=176926. OK, thanks. Bart. |
|
From: Paul M. <pa...@sa...> - 2008-12-22 22:43:37
|
Bart Van Assche writes: > A source code comment in m_machine.c says the following: > > /* ppc32 doesn't seem to have a sane way to find out what insn > sets the CPU supports. So we have to arse around with > SIGILLs. Yuck. */ > > I don't know everything about the PowerPC architecture, but by looking > around in the Linux kernel sources I found out that the Linux kernel > determines the PowerPC CPU type from the value in the PowerPC PVR > register. And although reading the PVR is privileged on PowerPC, under Linux the kernel will emulate the move-from-PVR instruction and supply the actual PVR value. So userspace can do a mfpvr to find out what sort of processor it's running on. The only problem with doing that is that you need some way to handle the case where you don't recognize the PVR value you get, because the processor is a new implementation that didn't exist when your program was compiled. Another way to find out what the hardware can do is to look at the AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. The AT_PLATFORM is a string such as "ppc970" or "power6" or "ppc750". The bits in AT_HWCAP are defined in <asm/cputable.h> and are: #define PPC_FEATURE_32 0x80000000 #define PPC_FEATURE_64 0x40000000 #define PPC_FEATURE_601_INSTR 0x20000000 #define PPC_FEATURE_HAS_ALTIVEC 0x10000000 #define PPC_FEATURE_HAS_FPU 0x08000000 #define PPC_FEATURE_HAS_MMU 0x04000000 #define PPC_FEATURE_HAS_4xxMAC 0x02000000 #define PPC_FEATURE_UNIFIED_CACHE 0x01000000 #define PPC_FEATURE_HAS_SPE 0x00800000 #define PPC_FEATURE_HAS_EFP_SINGLE 0x00400000 #define PPC_FEATURE_HAS_EFP_DOUBLE 0x00200000 #define PPC_FEATURE_NO_TB 0x00100000 #define PPC_FEATURE_POWER4 0x00080000 #define PPC_FEATURE_POWER5 0x00040000 #define PPC_FEATURE_POWER5_PLUS 0x00020000 #define PPC_FEATURE_CELL 0x00010000 #define PPC_FEATURE_BOOKE 0x00008000 #define PPC_FEATURE_SMT 0x00004000 #define PPC_FEATURE_ICACHE_SNOOP 0x00002000 #define PPC_FEATURE_ARCH_2_05 0x00001000 #define PPC_FEATURE_PA6T 0x00000800 #define PPC_FEATURE_HAS_DFP 0x00000400 #define PPC_FEATURE_POWER6_EXT 0x00000200 #define PPC_FEATURE_ARCH_2_06 0x00000100 #define PPC_FEATURE_HAS_VSX 0x00000080 #define PPC_FEATURE_PSERIES_PERFMON_COMPAT \ 0x00000040 #define PPC_FEATURE_TRUE_LE 0x00000002 #define PPC_FEATURE_PPC_LE 0x00000001 Is there anything you need to know about that isn't on that list? Paul. |
|
From: Bart V. A. <bar...@gm...> - 2009-01-07 15:36:15
|
On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: > Another way to find out what the hardware can do is to look at the > AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. Thanks a lot for this information. Can anyone tell me whether there is already support present in Valgrind for accessing the ELF auxiliary table, or where I should start looking ? Bart. |
|
From: Tom H. <to...@co...> - 2009-01-07 15:44:23
|
Bart Van Assche wrote: > On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: >> Another way to find out what the hardware can do is to look at the >> AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. > > Thanks a lot for this information. Can anyone tell me whether there is > already support present in Valgrind for accessing the ELF auxiliary > table, or where I should start looking ? Well m_main.c has a copy of the auxv in the_iifii.client_auxv once ii_create_image has run. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Julian S. <js...@ac...> - 2009-01-07 17:11:16
|
On Wednesday 07 January 2009, Bart Van Assche wrote: > On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: > > Another way to find out what the hardware can do is to look at the > > AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. > > Thanks a lot for this information. Can anyone tell me whether there is > already support present in Valgrind for accessing the ELF auxiliary > table, or where I should start looking ? At least for fixing http://bugs.kde.org/show_bug.cgi?id=176926, I would prefer to continue using the SIGILL scheme, unless there's a good reason to move the using the ELF auxiliary table. At least superficially, #176926 looks quite simple to fix -- catch SIGFPE as well as SIGILL in the relevant piece of detection code. J |
|
From: Bart V. A. <bar...@gm...> - 2009-01-12 17:39:20
|
On Wed, Jan 7, 2009 at 5:56 PM, Julian Seward <js...@ac...> wrote: > > On Wednesday 07 January 2009, Bart Van Assche wrote: > > On Mon, Dec 22, 2008 at 10:57 PM, Paul Mackerras <pa...@sa...> wrote: > > > Another way to find out what the hardware can do is to look at the > > > AT_HWCAP and AT_PLATFORM entries in the ELF auxiliary table. > > > > Thanks a lot for this information. Can anyone tell me whether there is > > already support present in Valgrind for accessing the ELF auxiliary > > table, or where I should start looking ? > > At least for fixing http://bugs.kde.org/show_bug.cgi?id=176926, I would > prefer to continue using the SIGILL scheme, unless there's a good reason > to move the using the ELF auxiliary table. At least superficially, > #176926 looks quite simple to fix -- catch SIGFPE as well as SIGILL in > the relevant piece of detection code. By this time I have attached a patch that implements SIGFPE catching to the mentioned bug item (https://bugs.kde.org/attachment.cgi?id=30135). This patch was reported to work on the 440EPX CPU. Is it OK if I commit this patch on the trunk ? Bart. |
|
From: Julian S. <js...@ac...> - 2009-01-12 20:14:56
|
> By this time I have attached a patch that implements SIGFPE catching > to the mentioned bug item > (https://bugs.kde.org/attachment.cgi?id=30135). This patch was > reported to work on the 440EPX CPU. Is it OK if I commit this patch on > the trunk ? Yes, pls commit. J |