ppc476 actual data cache line size and instruction cache line size both are 32. But we get data cache line size is 128 and instruction cache line size is 32 by valgrind. I can solve it using attached patch.
Created attachment 73808 [details] solve ppc476 cache line size error
The patch seems corrupted. Can you reattach?
Created attachment 74187 [details] remove data and insctruction cache line size judgement. remove data and insctruction cache line size judgement.
WIll need investigation to understand why the ppc cache line size detection logic didn't work here. Normally it works OK. I don't want to apply the patch without further analysis.
Hello, Per: arch/powerpc/kernel/cputable.c, it seems to be invariant that icache_bsize == dcache_bsize, except for the IBM PPC476 FP, where: { /* 476fpe */ .pvr_mask = 0xffff0000, .pvr_value = 0x7ff50000, .cpu_name = "476fpe", .cpu_features = CPU_FTRS_47X | CPU_FTR_476_DD2, .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, .mmu_features = MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST | MMU_FTR_LOCK_BCAST_INVAL, .icache_bsize = 32, .dcache_bsize = 128, .machine_check = machine_check_47x, .platform = "ppc470", }, which (I am told) feeds into auxv, which is read by: coregrind/m_initimg/initimg-linux.c/setup_client_stack() case AT_DCACHEBSIZE: case AT_ICACHEBSIZE: case AT_UCACHEBSIZE: # if defined(VGP_ppc32_linux) /* acquire cache info */ if (auxv->u.a_val > 0) { VG_(machine_ppc32_set_clszB)( auxv->u.a_val ); VG_(debugLog)(2, "initimg", "PPC32 cache line size %u (type %u)\n", (UInt)auxv->u.a_val, (UInt)auxv->a_type ); } So the above code is executed twice: once for case AT_DCACHEBSIZE (auxv->u.a_val == 128), once for case AT_ICACHEBSIZE (auxv->u.a_val == 32) leading to the assertion: vg_assert(vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB); failing in coregrind/m_machine.c/VG_(machine_ppc32_set_clszB) at its second invocation. Thanks due are entirely to my colleague at Freescale Semiconductor: James Yang (James.Yang@freescale.com), for these insights.
I looked at this and it appears that ppc_cache_line_szB is meant to be the size of the instruction cache - looking at how this value is being used. So we're not really interested in the size of the data cache and should simply ignore any such entries in the auxiliary vector. LIke so: Index: coregrind/m_initimg/initimg-linux.c =================================================================== --- coregrind/m_initimg/initimg-linux.c (revision 13479) +++ coregrind/m_initimg/initimg-linux.c (working copy) @@ -251,10 +251,6 @@ /*=== Setting up the client's stack ===*/ /*====================================================================*/ -#ifndef AT_DCACHEBSIZE -#define AT_DCACHEBSIZE 19 -#endif /* AT_DCACHEBSIZE */ - #ifndef AT_ICACHEBSIZE #define AT_ICACHEBSIZE 20 #endif /* AT_ICACHEBSIZE */ @@ -710,7 +706,6 @@ # endif break; - case AT_DCACHEBSIZE: case AT_ICACHEBSIZE: case AT_UCACHEBSIZE: # if defined(VGP_ppc32_linux) I'm planning to apply this shortly together with a change that renames vai.ppc_cache_line_szB to vai.ppc_icache_line_szB for clarity.
Fixed in VEX r2735 and valgrind r13481.