Reported location of variable in watch changes

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Reported location of variable in watch changes

      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 ...?
    • Hello,

      Thank you for your inquiry.
      Such an issue is not known to us.
      Generally Ozone gets that information from the elf file.
      Could you provide the elf file for reproduction purposes?

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/
    • 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.:

      C Source Code

      1. printf("addr = %p\n", &myvar);


      Looking at the disassembly, this compiles to:

      Source Code

      1. 0801 8A78 ADD.W R3, R7, #0x10
      2. 0801 8A7C MOV R1, R3
      3. 0801 8A7E LDR R0, =0x080B0070 ;[0x08018BBC]
      4. 0801 8A80 BL printf ; 0x080A4640
      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 ... )
    • Hello,

      Thank you for the additional information.
      The data location of the stack variable often depend on the frame base pointer register R7. When this register is corrupted by a subfunction call, the observed data location change for the stack variable would be explained.

      So this behaviour is caused by the application you are running.
      To work around this you could use a fixed type cast structur on a fixed address which you can then use as the watch variable instead e.g.
      *(MY_STRUCT*)0x2001C090
      This watch is no longer dependent of R7 and will always show the wanted stack variable.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/
    • Hello,

      Does the same issue appear with the V2.56w?
      We found some instabilities with the new V2.60e version and want to make sure this issue is not also related.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/
    • Hi,

      Quick update. We were able to reproduce the behaviour and a fix should be available with the next Ozone release.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/