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.