We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi arm experts,
I wrote some simple C functions to check if the result of memcpy is expected after enable MMU and data cache on Cortex-A53. The assembly (got by disassembling with aarch64-none-elf-objdump) of the one of these functions is very strange:
C code:
void mem_copy_check(void)
{
UINT32 *src = (UINT32 *)0x0, *dest = (UINT32 *)0x3101f300;
UINT32 i, len = 0xc00;
for (i = 0; i < (len/4); i++) {
if (*(src + i) != *(dest + i)) {
TRACE("mem_test(): check SCU_TCM failure, i: %d, src addr: 0x%x, src val: 0x%x, dest addr: 0x%x, dest val: 0x%x\n",
i, src, *(src + i), dest, *(dest + i));
return;
}
After compile, assembly code:
0000000000000878 <mem_copy_check>:
878: d4200020 brk #0x1
I found the variable "src" being "0" cause this "brk" instruction while there is no abnormal if the variable "src" is non 0. But, feel confusion since the code just "read" data from 0 but not write to.
I am using armclang v6.01.
This looks like a compiler 'feature' in that it has recognized that src has been set to NULL - and since the code always accesses *src all it should ever do is fail according to the spec. The compilers are getting excessively clever, you'll need to do some trick like have a global with the value 0 and load that or have it initialised to 4 and then decrement it.to get round the compiler