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.

Debugging Run-Time Relocatable Code

CCS 5.1.0M5
55x Rev 2.x Functional Simulator

Is there a method for debugging run-time relocatable code?  I've attached a simple example project to demonstrate the issues encountered.  Specifically, even though I'm setting a breakpoint on the "add" function, CCS always trys stepping through the "sub" function!  I can understand why CCS is confused, but is there any way around the issue, or anything you can do to make this work better?

relocatable.zip
  • Brad,

    Quite interesting. I can see the same issue here. I am still investigating some details and will get back to you on that, ok?

    Cheers,

    Rafael

  • Brad,

    It seems a disconnection between the source code view and the actual breakpoint. Just to confirm, is this what you see when you open the disassembly view?

    If you notice, the disassembly shows the source code for the Add function, not the sub.

    Cheers,

    Rafael

     

  • Rafael,

    Thanks for looking into this issue.  Interesting observation!  I didn't even have the Disassembly window open so I didn't notice the behavior you described.  I just tried it and can confirm that I see the exact same behavior.  So the disassembly window seems to "know" which code is being executed but nothing else does.  As a test I modified the definition of the "sub" function to call its arguments "arg3" and "arg4".  It looks like the Variables window is also confused, i.e. it shows the local variables for the "sub" function even though I'm actually executing the "add" function.  Here's a screenshot:

  • Brad,

    It seems a disconnection between the way the debug information is being translated when creating the disassembly view and the other views.

    If you keep running your code, you will see that the debugger halts at the same position again. In other words, all the views keep displaying the same information: the source code view remains halted at the sub function and the disassembly view still shows the add function source code.

    The fact that the source code is being displayed incorrectly should not happen, therefore I will file a bug.

    I noticed this issue also affects previous releases of CCS, therefore I imagine this has no easy fix (or maybe it is a corner case that was never reached by customers).

    From the standpoint of halting at breakpoints, I think this is due to the fact that hardware breakpoints are set per physical address. Therefore the debugger will halt its execution every time the PC register is equal to a given value. Since the simulator mimics the hardware, the same behaviour occurs.

    Regards,

    Rafael

  • Looking at things a bit more, I see that the disassembly view always thinks I'm running "add" while the source view always thinks I'm running "sub".  Yuck.  I have a medical customer who was locked on CCS 2.21 for many years that is finally moving to the latest CCS.  They tell me that this functionality worked fine for them in CCS 2.21 but it's broken in CCS 4.2.3 (and I can confirm it's still broken in 5.1.0m5).

  • Brad,

    Filed SDSCM00040719 today.

    Cheers,

    Rafael

  • Update!  With some behind the scenes help from the CCS team I was able to get this working in CCS 5.1.0.

    I've attached an updated example.  You need to use the gel file included in the zip to make it work.  The basic procedure is to take advantage of the GEL functions GEL_SymbolShowSection and GEL_SymbolHideSection such that only the code you are actively debugging has symbols defined as seen by CCS.

    A few notes:

    1. You must set the compiler's Debugging Model to "Full symbolic debug (COFF, deprecated) (--symdebug:coff)" or else it will not work! 
    2. The GEL functions require a complete path to the out file be passed.  In other words, if you try out my project you will need to modify SYMBOL_FILE_PATH in the gel file to point to the location where you built the example.  Furthermore, if you switch between debug and release you will need to change the gel.  Also, other developers who have the project at a slightly different path on their PC will need to adjust accordingly.  (Moderately annoying -- I'm trying to see if we can find a way around that issue.)
    3. Make sure you use double backslashes in the path names when setting SYMBOL_FILE_PATH.

    Now you should be able to step into add() and subtract() and it should work without a hiccup.

    Best regards,
    Brad

    example.zip