how it is that pointer to struct shows the wrong values?

Question

I use ARM-M4 with GCC for ARM (10_2021.10) I have a problem where a pointer to struct displays the wrong values.

__copy_table_start__ is define in the linker file, I see it's location in the map file and this is how I found it's true value (and the values make sense, they are correct)

Here is my code

#pragma GCC optimize("O0")
static void DataInit(void)
{
    typedef struct {
      uint32_t const* src;
      uint32_t* dest;
      uint32_t  wlen;
    } __copy_table_t;

    extern const __copy_table_t __copy_table_start__;
    extern const __copy_table_t __copy_table_end__;
    extern const __zero_table_t __zero_table_start__;
    extern const __zero_table_t __zero_table_end__;

    static volatile __copy_table_t const* pTable;
    
    pTable = &__copy_table_start__;

    for (; pTable < &__copy_table_end__; ++pTable) {
      for(uint32_t i=0u; i<pTable->wlen; ++i) {
        pTable->dest[i] = pTable->src[i];
      }
    }
}

And what I see in the debugger, right after pTable = &__copy_table_start__; is that:

__copy_table_start__.src = 0x14A0D380
__copy_table_start__.dest = 0x00100000
__copy_table_start__.wlen = 0x38A

pTable->src = 0x14A0D380
pTable->dest = 0x14A0D380
pTable->wlen = 0x14A0D380

How can that be?

UPDATE: I did another experiment, I created another struct variable and a pointer to that variable and get the same results. first time I see this kind of behavior.

const __copy_table_t mine = {(uint32_t const*)0x12345678, (uint32_t *)0x00004545, 0x89890000};

static volatile __copy_table_t const* my_ptr;
my_ptr = &mine;

The result is that my_ptr->src = my_ptr->dest = my_ptr->wlen = 0x12345678

Answer 1

Apparently the problem is with Keil (the IDE). It displays the wrong values.

When I created 3 new parameters and loaded the data to them:

my_src = (uint32_t)pTable->src;
my_dest = (uint32_t)pTable->dest;
my_len = (uint32_t)pTable->wlen;

Those parameters got the correct values. What threw me off was that doing a single step in debug skipped the entire for loop (the first one), as if the internal for loop didn't do anything. It actually did what it was supposed to do, but one parameter that was supposed to be reset after that didn't update in the IDE.