This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EP Trace startpoint problem.

Hi All,

   I'm getting the following message when starting the EP Trace facility at a specific PC in a program:

The disassembled code around this PC is as follows:

The PC referenced is highlighted above. It is at a short call to another function. It is definitely not in an SPLOOP block and the only way to get to this instruction is through the predicated branch at 0013e304. Now directly above the PC is a BNOP 5 instruction. Since there are 5 delay slots filled with NOPs here, this is not a problem. Is the EP Trace facility erroneously seeing this situation as being in the delay slots of the BNOP instruction?

The software version I'm working with is: CCS v5.1.0M7 Linux.

Thanks,

Mark Brown

  • Mark,

    Unfortunately I am not an expert in EP Trace, but I will ask for the help of the simulation experts.

    A few remarks:

    - the version of CCS you are using is a pre-release; can you download and test this scenario with the production version of CCS?

    - the .out file may be needed to further investigate this issue.

    Regards,

    Rafael

  • Hi Mark,

    The particular warning should come if EP trace start point isenabled winthin delay slots of a branch instruction. From the snapshot, I dont see the start address is in branch delay slot. I have an internal bug(SDSCM00042755) for tracking. Please send the .out also if you can.

    regards.

    Sheshadri

     

  • Sheshadri,

       Unfortunately the .out file is too large and it is on a proprietary network and cannot be sent. I'm not sure that I can recreate the exact code sequence with a small custom testcase. If you absolutely need to look at the .out file we may have to make other arrangements for access.

    Thanks,

    Mark

  • Hi Mark,

     I will try and reproduce myself in that case. I am planning to work on this bug in Feb. Will keep you updated on progress.

    regards,

    Sheshadri

     

  • Sheshadri,

       Good news. I was able to put together a small testcase that has the same issue. The C source is as follows:

    The associated javascript for the DebugServer is:

    You may have to check the breakpoint addresses after you build your version.

    Thanks,

    Mark Brown

  • Hi Mark,

    I tried building the .out from your source file and applying break point at "uwresult = Function1();" source line. After this I started EP trace and it did not give any errors and I was able to run beyond and generate EP trace file. One difference I am seeing is the code generated is using "callp" instruction for function calls while your compiler version is generating branches probably. So in order to ensure we are on the same page as far as build env goes, can you just fwd the .out to my mail id. I will again try and reproduce.

    regards,
    Sheshadri

     

  • Sheshadri,

       You can't use the GUI to build this and set the breakpoint on a source line. That is why I sent the javascript file to use it with the dss.sh script on linux. You need to set the breakpoint at a specific address as provided in the javascript file. To compile and link the testcase, use the following command in a shell:

    You will also need to setup the processor configuration files referenced in the javascript as well.

    Thanks,

    Mark Brown

  • Mark,

    I managed to reproduce this issue as well while working in your other post. I will follow up with the simulation expert and see if he has additional details on this issue and a possible workaround.

    Regards,

    Rafael

  • Hi Mark,

    I have debugged the issue w/ the case that  Raphael has sent. This is a bug in EP trace because we are considering enablng EP trace in delay slots of even "untaken" branches as not allowed. What is happening is.. the control jumps from 0c00d4f8 to 0c00d510 (where break point is set and EP trace is enabled). As can be observed, the last instruction in the delay slot of branch (at 0c00d4e4) is another branch which is not taken ( at 0c00d4f8). The EP trace is wrongly notifying  that Break point is enabled in delay slot of a branch which in this case is not a taken branch.

    0c00d4e4:   D0000612 || [!A0]  B.S2          $C$L1 (PC+48 = 0x0c00d510)
    0c00d4e8:   0202302A           MVK.S2        0x0460,B4
    0c00d4ec:   02000F28           MVK.S1        0x001e,A4
    0c00d4f0:   020600EA           MVKH.S2       0xc010000,B4
    0c00d4f4:   018600E8           MVKH.S1       0xc010000,A3
    0c00d4f8:   C0007C10    [ A0]  B.S1          printf (PC+992 = 0x0c00d8c0)


    C$L1:
    0c00d510:   0FFFF890           B.S1          Function1 (PC-60 = 0x0c00d4c4)

    This is not  a correct interpretation. While I fix it, which may take another week, there is a work around you can try for the testcase attached by Raphael.

    Try changing the EXPECT_EQ macro into an inline function as shown below,  I observed that compiler is generation CALLP instructions and the above condition is not replicated. I was able to set break point and generate EP trace file.

    #define UT_FAILURE 1
    inline int EXPECT_EQ(int expt, int result)
    {
     do{
      if (expt != result)
      {
       printf("[ERROR] %s(): %d: expect=0x%08x, result=0x%08x\n",__FUNCTION__,__LINE__,expt, result);
       return UT_FAILURE;
      }
      else if(0)
      {
       printf("[EQUAL]%s(): %d: expect=0x%08X, result=0x%08X\n",__FUNCTION__,__LINE__,expt, result);\
      }
     }while(0);
     return 0;
    }

    regards,

    Sheshadri