I am debugging a project with Ozone, and I am seeing something that I do not understand the cause of.
It may have a clear cause ... or it may be an Ozone bug. I'm unsure.

In the code that I debugging, I am setting a watch on a stack variable (a struct), and Ozone reports the location as 0x2001C090. The size is correctly reported as 121 bytes.
After a returning from the call to a function that is suspected to contain bugs (by step-over before entering), the location reported by Ozone changes to 0x20000010. The size is still shown as 121B.

The MSP and PSP appear to not be affected by the suspect function when stepping over it.

Where is Ozone pulling the location information from? I am not even sure what kind of corruption or overflow could be happening to clobber that, since it should just be pulled from the ELF file ...?

I can't profile the elf, since it would contain our proprietary source. Maybe if we put an NDA in place? But then you would need very specific hardware for the ELF to even run.

This issue also happens when using gdbserver + eclipse + GNU Arm Eclipse plugin suite; the behavior is reproduced in the Eclipse watch window.

How is Ozone/Jlink even resolving the variable name to a location? There isn't a symbol in the ELF for it, as far as I can see ...

Alright, for a little more exposition, the error can be captured in a simple printf of the address before and after the function call.
e.g.:


Looking at the disassembly, this compiles to:

Where 0x080B0070 is the address of the const string.

So it looks like R7+0x10 = 0x2001C090 is storing the address of the variable.

In the suspicious function, R7 is getting stacked, but then the incorrect value in unstacked, ergo my suspicious function must be clobbering my stack frame (or the RTOS is corrupting something).
Upon function return, R7 is reloaded with the corrupted value, so R7+0x10 is now pointing to the wrong place.

I guess this comes down to how the debugger has to try and make a fake "symbol" or expression to represent the local stack variable, since it is not a proper object symbol after compilation. So it is really only an inferred location, and I suppose it can only ever infer it when loading the ELF.

(Also ... couldn't the Jlink itself enforce a check that detects or instruments a C function entry and checks for C stack corruption on return? That would be pretty great ... )

One follow-on here:

If I try to enter in a watch of *(uint32_t*)0x200221D8 , Ozone crashes immediately.

Version 2.60e running on OSX 10.14 Mojave.

Adding that watch does not cause a crash in 2.56w .

I have had a lot of other problems with versions > 2.60 , hangs and crashes when resetting and reflashing. Looking forward to things getting stabilized.