arm-none-eabi-gcc : unable to see local variables in modeldebugger

Thanks, Andy for the response !

I have disabled - or so I think- optimization via option -O0 (as in letter 'O'zero) and that does not make any difference.

Here's the initialization in my main.c

typedef volatile unsigned int * memaddr_t;

#define RAM_DMA_BLOCK_SIZE		1024
#define RAM_DMA_BLOCK_SRC 		0x00000200
#define RAM_DMA_BLOCK_DST 		0x00001300

void
__main(void)
{
    memaddr_t dmaSrcStartAddr = ((memaddr_t) RAM_DMA_BLOCK_SRC);
	memaddr_t dmaDstStartAddr = ((memaddr_t) RAM_DMA_BLOCK_DST);
	unsigned int blockSize = RAM_DMA_BLOCK_SIZE;
	
	for (int i = 0; i < blockSize; i++)
	{
		*dmaSrcStartAddr = 0xa5a5a5a5;
		*dmaDstStartAddr = 0x0;
		dmaSrcStartAddr++;
		dmaDstStartAddr++;
	}
	
	unsigned int foo = 0x11;
	foo++;
}

Now when I run the code in the modeldebugger , step into main, the debugger cannot resolve teh contents of the local variables as shown in my screen-shot. It sees the local variables, but is unable to access the corresponding memory.

I see identical behavior on Windows & Linux platforms. Was thinking if using arm tools (arm compiler toolchain) rather than gnu one would help, but its not so trivial to port even a simple target  from arm-none-eabi-gcc toolchain to a newbuild environment; looking into it.

Hi Andy,

Also, I notice that if I declare the program variables in global scope i.e. declare/define dmaSrcStartAddr, blockSize etc before main() then the debugger sees it just fine; since as expected the memory allocation of these is set at compile time and the exact address where they get allocated is easily seen from the linker map file.

So, basically the issue occurs for local variables in the main() that get allocated on the stack - for some reason the debugger cannot see it - I can infer it from the register contents but that's very tedious and error prone when stepping through the  C code.

Suspect this has to do with stack area allocation ? My linker script is as follows, I do not have explicit .stack section in it:

SECTIONS
{
    .  = 0x0;         /* From 0x00000000 */

    .text : 
    {
        *(vectors)    /* Vector table */
        *(.text)      /* Program code */
    }
    .rodata : 
    {
        *(.rodata)    /* Read only data */
    }

    .  = 0x00002000;  /* From 0x0002000 */      
    .data :
    {
        *(.data)      /* Stack memory */
    }

    .  = 0x00008000;  /* From 0x0008000 */      

    _BSS_START = .;   /* Indicates where BSS section starts in RAM */
    .bss :
    {
        *(.bss)       /* Zero-filled run time allocate data memory */
    }
    _BSS_END = .;     /* Indicates where BSS section ends in RAM */
}

Investigating further I don't think the linker script has an issue, even when I had a .stack region allocated the issue persisted.

Within the main() if I declare a variable as static then again the debugger sees it at run time. So my best educated guess is that the debugger cannot resolve the symbols that are in automatic scope, for some reason. Not tried looking into the different debug formats (stabs, dwarf etc.) which one do ARM native tools work with seamlessly.

For now I can workaround with debugging declaring variables in global scope or static if in local scope and once all is good revert them as automatic variables in local scope and move on. Would like to get a resolution to the issue -if someone can enlighten me

I'd still say that's likely down to "optimisation".

eg, the compiler has not put those things in memory - just in registers.

The compiler is not obliged to generate "useless" code - even if "optimisation" is turned off.

Well, then there should be some way / hook to turn that so called optimization off to debug embedded code, shouldn't it be  - like the compiler writers do not know that - I do not believe it. Do u know how to get around it if you think that is the reason  ? There is an option -Og that tells the compiler to "optimize" code that is debugger friendly, have not tried it, but am 99% skeptical it won't work. Will check that out. On the same lines - and to your point - I plan to build it with armcc when I get the cycles to do so and update my findings

I found a resolution to this - finally.

The model debugger successfully shows the local variables when target is built with DWARF2 debugging format, so building the target code with -gwarf-2 option fixed the issue. The default format of debugging info, I believe stabs does not work